Ok, still tooling on this one.  I have a question here about interrupt
handling.

Currently, the code in hp300/isr.c maintains three sorted lists
of interrupt handlers, one for each of the ipl's 3, 4, and 5.

The frodo (utility) chip generates an interrupt at ipl 5, but it's
effectively another ICU, with 15 internal interrupt sources.  Several
of these, however, may want to be transparently vectored (eg. because
they come from the ISA bus, or because we may want to use MI drivers,
or something else magic).

So I need to find a way for isrlink() to be able to handle this,
rather than having the frodo driver just hook ipl 5 and have its
own set of interrupt management functions.

One scheme would be to hijack some of the spare bits in the top
of the (ipl) parameter to isrlink(), one to advertise that a handler
could handle nested interrupts, another to indicate that an ipl
was nested and several to represent the sub-ipl value.

This would be transparent to the existing code, but kinda 
disgusting.  Are there any better ideas?

--
Mike Smith  *BSD hack  Unix hardware collector
The question "why are the fundamental laws of nature mathematical"
invites the trivial response "because we define as fundamental those
laws which are mathematical".  Paul Davies, _The_Mind_of_God_