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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
