>(Unless you are talking about complicating that by calling soft2 if
>returning to a frame at PL<2, etc. which I doubt.)

That *is* what I meant, and this is exactly as useful (if a bit more
difficult in software :-) ) as having intermediate-level software
interrupts in hardware.

>Am I missing the point of your objection?

I was not objecting, but simply bringing up a point that should be
considered.  Hence my comment that:
  Exactly what sort of argument this forms, if any, is not really clear.

>>The zs hard/soft interrupt split is machine-dependent anyway ...

>True.  Does this mean you think the zs code should not use the
>proposed softint_* functions?

I am not sure.

>If so, why not?

The obvious `pro' argument (to use an MI interface in an MD manner)
is Occam's razor.  The obvious `con' argument is that this is
machine-dependent anyway.  Which argument is stronger, or any other
less-obvious arguments, I am not willing to guess here.

Someone else was curious as to how the DECstation Zilog SCC driver
could keep up at high bit rates, without having a split-level scheme
like the Sun.  The likely answer is that it does not.

Because of its worthless FIFOs, the ZSCC imposes some relatively
hard real-time constraints.  Sun's solution to the problem was to
allow, and in the process end up requiring, the software to simulate
a larger FIFO.  The hardware allows it by placing the interrupt
priority very high (ipl 12: above all but the audio device at 13,
the profiling clock at 14, and machine checks at 15).  The requirement
occurs because ipl 12 is `too high' for ordinary tty priority: it
would be unreasonable to block most interrupts for most tty software
structure manipulations.  Thus, we pick some appropriate lower
level at which to implement the `corrected' software version of
the ZSCC.  This could be done at soft{net,clock} level, but other
tty hardware (various Sbus boards) works reasonably well at ipl 4
or 6 or so, so spltty must be at least that high to support them,
and hence ipl 4 or 6 or so seems like a reasonable place to put
the `corrected' software ZSCC driver.

The DECstation does not wire its ZSCC interrupts at a high priority,
so there is no reason (nor way) to split it in this manner.  On
the other hand, one can pick some existing high-priority, frequent
interrupt (assuming there is one), and use it to poll the Zilog
chip(s).  This is architecturally similar, but the code for talking
to the hardware will be different.  (Of course, it will be different
anyway, since the MIPS has no byte-wide I/O-bus transactions.)

Note that this is not exactly the same as the old trick used on
the VAX to `fake' a silo alarm on hardware like the DZ-11, but it
is similar enough to make it worth looking at the old code. :-)

Chris