Interrupt API change

[Bruce Evans]

On Fri, 9 Jan 2004, Scott Long wrote:

> At the September DevSummit, Peter Wemm proposed changing the device
> driver API so that interrupt routines return an INT instead of a VOID.

This design error was rejected last time it was discussed (about 8-10
years ago).

> The primary purpose of this is two-fold.  The first is so interrupt
> handlers can communicate back to the low-level interrupt routines
> whether or not they were able to handle the interrupt.  Heuristics
> can then be built on this information to better detect things like
> interrupt storms.

That'a about all it can do.  In the shared irq case, there is no
alternative to calling all the handlers if one of the handlers did
something, since activity by one handler is unrelated to activity by
others (except as an optimization that only works in the edge triggered
case -- devices usually rarely interrupt concurrently so assuming that
thety never do is usually most efficient).  In the non-shared case,
individual handlers can better decide about interrupt storms in a
device-specific way.  The non-shared case will hopefully be almost all
cases when APIC support becomes standard on i386's.

> This change also paves the way for the proposal
> to make interrupts be multi-tiered.

That is another reason not to do it.  Interrupts shouldn't be multi-tiered
except in special cases.

> The first level interrupt handler
> can relay back whether it wants the second-level handler to be run
> (similar to filter interrupt handlers in Max OS X).

The first level interrupt handler should call (or schedule) other levels
as necessary (as in RELENG_4, but not using inefficient scheduling as in
-current).

Bruce