> 
> >There may be more than one "soft interrupt" level ...
> 
> But there may not, and (as on the i386) soft interrupts might even
> have to be handled entirely in software (in which case you could,
> of course, have an arbitrary number of softint levels, depending on
> how much work you wanted to do in the spl functions).
> 
> Exactly what sort of argument this forms, if any, is not really clear.

I thought the argument was that if something's to be M.I., and to take
over a lot of functionality (a thrust I thought was in the original
suggestion), it has to accomidate everyone's quirks.

> >... so this MI interface could not replace the currently MD facilities
> >in the sun3 or sparc ports
> 
> The zs hard/soft interrupt split is machine-dependent anyway: on
> the DECstation, there would be no reason to make such a split.
> The same argument may apply to audio interrupts as well.

Huh? I see that you're correct about how the pmax/tc/scc.c driver
seems to work, but how do you (does it) ensure reliable operation
at high speed? Running with this example, since the silly chip
has such a small fifo, we need to get bytes out of it quickly.
But we aren't supposed to feed them to the tty system if we're at
spltty, so we need an intermediate buffer (a silo in the parlance
of the 4.3BSD book). So we need two interrupt levels.

It seems the pmax port does a polling of the serial chips. So this
polling happens when spl < spltty? I'm curious how it's assured
that this polling happens often-enough to keep up w/ 57600 or
115200 (once every 520 us or 260 us respectively)?

Take care,

Bill