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