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