When I used loadable drivers on a relatively fast machine
(P2/400) I observed some strange behaviour - unexpected
interrupts and hangs. Here is my preliminary analysis:

If an interrupt handler is inserted at runtime, it might be called
earlier than one expects, independently of the current interrupt
level (ie, even at splhigh).
The reason is that the interrupt mask bits are only set for
interrupt handlers which were already known at the point the
splwhatever() took place. If a handler is installed for an interrupt
which was not used before, it will be enabled immediately.
Even if we had an interrupt level setting cpl to -1, ie to
block really everything, it would be enabled by the next
splx(s) because the local "s" still reflects the old mask.

There is a related problem with the order of operations
within isa_intr_establish(): The new interrupt is enabled
in the ISA interrupt controller before the new handler is
inserted into the queue. If the device manages to issue an
interrupt before the handler is there, the box hangs in a
loop because the device interrupt (level triggered) doesn't
get cleared. (If the interrupt is not masked in the cpl.)

What to do here?

For the former, the only way I see is to mask all unknown
interrupts in the interrupt masks from the beginning.
The new interrupt would then be enabled when the system
returns to spl0. Would there be side effects? (besides
that stray interrupts are not noticed anymore)

The latter could be worked around if we always mask out the
new interrupt before isa_intr_establish() is called.
Or the SET_ICUS() could be moved down a bit.

Opinions, comments?

best regards
Matthias