locking in a device driver

[Julian Elischer]

Scott Long wrote:

> 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


depends on what they are using it for..
if it's  a WAN interface, then splimp. (INTR_TYPE_NET)

if ppp or several other moduels are loaded, teh tty and net masks are 
combined anyhow..

>
>>
>>> 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