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.


More information about the freebsd-hackers mailing list