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 ?
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
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 ?
--
Regards, /\_/\ "All dogs go to heaven."
[EMAIL PROTECTED] (0 0) http://www.alphaque.com/
+==========================----oOO--(_)--OOo----==========================+
| for a in past present future; do |
| for b in clients employers associates relatives neighbours pets; do |
| echo "The opinions here in no way reflect the opinions of my $a $b." |
| done; done |
+=========================================================================+
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
