> Date: Sat, 6 Apr 1996 14:12:52 -0700 (MST)
> From: Chris Torek <torek@BSDI.COM>
> 
> >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).

When soft interrupts are handled entirely in software, you have only
one level because the software implementation calls the soft interrupt
whenever an interrupt handler is about to return to a "level 0" frame.
(Unless you are talking about complicating that by calling soft2 if
returning to a frame at PL<2, etc. which I doubt.)  The number of
levels is independent of the number of attachments at one level.

> Exactly what sort of argument this forms, if any, is not really clear.

The argument is that the public interface can easily allow expression
of desired functionality on both kinds of systems.  The common systems
that have only one "software interrupt" would define all the priority
symbols as 1 and fail the softint_attach() call if any other priority
is asked for.

I don't see how the proposed "priority" scheme does any harm to
systems with only one software interrupt level.

Am I missing the point of your objection?

> >... 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.

True.  Does this mean you think the zs code should not use the
proposed softint_* functions?  If so, why not?

[ setsoftnet(), setsoftclock() ]
> These have always been the same priority, and there is no real reason
> not to collapse them into one level.

Perhaps, though I don't see a direct relevance.

The "softnet" and "softclock" work _can_ be done all at the same
level, but I can imagine that it might be interesting to experiment
with putting softnet at level 2 on a sun, for example.  Both the
current and proposed interface would allow that, so why not continue
to allow the MD code to have that flexibility?

Gordon