Robert Swindells wrote;

> I think that the current interrupt mechanism relies on there being
> slightly less than 32 real interrupt sources so that there are some
> bits free for soft interrupts.

There are several ways to implement softintr() besides simulated
interrupt solution (are you familiar with a term "AST"?)  This is one
of most interesting aspects of how NetBSD can adapt various HW.

Some CPU, including ARM SoC, provide HW assistance of software
initiated interrupt.  With such the HW, softintr() can be handled
exactly same as real (external) interrupt context.  It's option to rely
on the HW assistance or not.  I once used the feature to implement
softintr() with one ARM9 SoC.  While it worked well, I decided not
to use it in the end and took advantage of unused free bit positions
in a single 32bit interrupt mask.  Alternatively, softintr() cause
notification could be placed in an independent global variable in
my case.

I think the variable name convention seen in some ARM port is rather
confusing.  I renamed the key global variables to "_toblock" and "_deferred"
for clarity.  Either is 32bit length bit vector, not the spl level number nor
IRQ #. The latter is to accumulate and record "caught but deferred" interrupts
and the former is to "gate" which interrupt should be blocked given any
moments.  For 64 way case this scheme is ill-fit and ep93xx_intr.c is not
a good example to cope with, I believe.

Toru Nishimura/ALKYL Technology