Once again as I meddle in midi(4) I have one of my "this might
be right, as I've never seen a problem, but I want to be sure"
questions.

A write(2) handler runs in kernel context and fills a bounded
buffer. A device handler consumes from the buffer; it can run
in interrupt context either at a device interrupt or a callout.
Both components protect their accesses to the buffer pointers
with splaudio() which is somewhere defined as

      #define splaudio splbio               /* XXX */

My question is: is this approach sufficient on MP? Do I have
any guarantees about which processor runs the write handler,
or fields the device interrupt or callout? Does splraise
affect any other processor? (My glance at the code looked like
no.)

It seems to me that reading and writing the buffer are really
not the hard part. I don't expect more than one writer at a
time (driver allows only one open - hmm, what if proc holding
fd forks? - can I assume kernel common code serializes calls
to cdevsw.d_write on the same device?) and I'll allow only one
active reader, so it's the simplest case of bounded buffer
problem and could be done with two pointers and no magic at
all as long as pointer writes are atomic and a barrier prevents
reordering them. In this light it seems that in some of the
buffer accesses guarded by spl macros the real "active ingredient"
in the macro is the barrier, and the spl effect is incidental.

On the other hand, what really should be critical sections are
the decision to block or wake the writer, and arm or disarm the
device transfer - and I think I can see how to handle that with
simplelocks, but I don't see how spl alone suffices.  Perhaps
it could be done with simplelocks alone if those didn't disappear
completely without MULTIPROCESSOR defined (say, if they degenerated
into non-buslocked TAS or something). So, hmm, simplelocks (for MP
case) /inside/ spl...splx (for UP case)?

Or, if there's something I fundamentally don't understand about
why it should really be safe with just the spl macros, I'm
counting on somebody to point that out.  ;)

Is there a document on the website somewhere about the driver-
writing implications of MP and the preferred approaches used in 
NetBSD?  I saw the other driver guides and FAQs but not much MP.

Thanks,
-Chap