Oh, it's a very nice summary how interrupt handlers are organized.

Todd Whitesel <toddpw@best.com> makes briefing of dispatchers;

> So you want to optimize for the single bit case, but still behave correctly
> in the multiple bit case. If the interrupt logic is all level-sensitive
> (and I expect it is), then you can get away with handling one interrupt at
> a time; the hardware will just throw you back into the interrupt handler
> if there are still any bits set.

It remind me that how R4030/R4230 'ARC chipset' (a.ka. IOASIC found in
DECstation) reports interrupts pending.  It's supposed to report
interrupt numbers in order for each read from highest priority to
lowest when multiple interrupts are posted asking services.   In the
following pseudo code segment;

void    
lbus_iointr()
{
        int devno;
        struct intrhand *ih;

        while ((devno = *(u_int8_t *)LBC_INT_IREQ) != 0) {
                ih = intrtab[devno >> 2];
                (*ih->hand)(ih->arg);
        }
}

where LBC_INT_IREQ returns interrupt number for each read.

One of the issues in how interrupt dispatchers is organized is the
existence of 'option cards'.  To ensure the correct 'system priority
level', interrupt establishment/dispatching framework must be aware of
what the type of devices are populated in 'option slots' (think about
NetBSD/i386).  NetBSD/pmax internal does not cope with the whole
picture in this moment.  For NetBSD/arc case, it should be smart enough
for mixing local bus devices governed by R4030/R4230 and any
combination of ISA, EISA and PCI devices.

Tohru Nishimura
Nara Institute of Science and Technology