> On Sat, 7 Jan 2006, Nathan J. Williams wrote:
>> other CPUs. The most conventional way to do this looks like:
>>
>> Top half:
>> splfoo()
>> simplelock();
>> ...
>> simpleunlock();
>> splx();

Oh good - that looks a lot like what I was arriving at from
first principles.  I like when that happens. :)

>> Bottom half:
>> [already at splfoo]
>> simplelock();
>> ...
>> simpleunlock();

Now in the midi case, we have an MI driver that can attach to
a bunch of different hardware transports, or to umidi, so I
wonder if the first line is

   [already at spl??? whatever the underlying HW driver is at,
    or splusb, or splsoftclock if resulting from a callout]

I'd assume that /when the bottom receives control because the
hardware interrupted/, whatever spl it's already at is sufficient
to prevent being itself interrupted by the same hardware (say,
after writing the first of several bytes) - but I'm not sure that
will be true when it gets control from the callout. At splsoftclock
it surely won't be able to interrupt the top half (if that's at
splaudio), but once running it could still be interrupted by itself
triggered by the real hw. So maybe this bottom half should still
use splaudio in addition to the simplelock.  Assuming splaudio
really is at least as high as the highest of any of the real
hardware gizmos we could be attached to. I see it's at least as high
as all three possible values for splusb ... my head's starting to
hurt.

Should I go ahead and include simplelocks now, or is that just
stealing the fun of the lucky people who get to audit kernel
sources whenever the biglock is eliminated?

-Chap