locking in a device driver

Scott Long scottl at samsco.org
Tue Nov 1 11:51:21 PST 2005


Dinesh Nair wrote:
> 
> 
> On 11/02/05 03:02 Julian Elischer said the following:
> 
>> drops to splzero or similar,..
>> woken process called,
>> starts manipulating "another buffer"
>> collides with next interrupt.
> 
> 
> that makes a lot of sense, i'll try with using splxxx() in the pseudo 
> driver, to block out the real driver. it's currently splhigh() due to 
> INTR_TYPE_MISC being used, but i guess i could change this to 
> INTR_TYPE_NET or INTR_TYPE_TTY. what would be good for a 
> telecommunications line card which is time sensitive and interrupts at a 
> constant 1000Hz ?

INTR_TYPE_TTY and spltty

> 
>> it needs to call splxxx() while it is doing it..
>> I would suggest having two buffers and swapping them under splxxx() so 
>> that
>> the one that the driver is accessing is not the one you are draining.
>> that  way teh splxxx() levle needs to only be held for the small time 
>> you are doing the swap.
> 
> 
> 
> the first buffer is actually the buffer into which DMA reads/writes are 
> done. what i referred to as "another buffer" is in fact a ring of 
> buffers. the real driver writes into the top of the ring, and increments 
> the top ring pointer. the pseudo driver reads from the bottom of the 
> ring and increments the bottom ring pointer.
> 
> buf1 buf2 buf3 buf4 buf5 buf6 buf7 buf8
>       ^         ^
>       |         |
>       |         +-- top ring pointer, incremented as real driver reads
>       |             from device
>       +-- bottom ring pointer, incremented as userland reads from pseudo
> 

You'll also want to use an spl in the top half of the pseudo driver to
cover where the pointers are read and changed.

> 
>> not locks, but spl,
>> and only step 8 needs to be changed because all teh rest are already 
>> done at high spl.
> 
> 
> wouldnt a lockmgr() around the access to these ring buffers help since 
> we're locking access to data and not necessarily execution ?
> 

lockmgr is far to heavy-weight and complex for this.

Scott


More information about the freebsd-hackers mailing list