In my effort to port NetBSD to the 8260, i've started to deal with the
interrupt handler (surprise surprise), because a flaw exists in the 8260
such that the DEC register does not actually decrement.  Ever.
Fortunately, Motorola has provided another periodoic interrupt timer,
however its interrupt is delivered through the 8260's interrupt
controller, rather than through a software vector as the decrementor is.

Therefore, its best to have full external interrupt support setup, and
then just bind in the timer's handler for the clock -- this is what
I did under Linux.

Where I'm having a problem is I don't fully quiet yet get how NetBSD
handles its interrupts.  When an interrupt is delivered to the core, it
calls the interrupt handler, which promptly attempts to raise the
interrupt mask to its highest level.  This is done by setting all of the
bits in cpl.  Then it looks at the old value of cpl, and tries to
determine if the interrupt currently being caught was already masked.
 If it was, its marked in the pending mask, and the handler returns.
Otherwise, it calls the handler, and the handler lowers the priority to
whatever it feels is best for it to run at.

Priorities are stored in an array of 32 bit integers, where each bit
corresponds to a single interrupt.  IRQs are muxed onto these through
some form of mapping, and that is it.  My question is:  why can't these
be layed out differently?  For example, couldn't I make the priorities
structs, holding 2 32 bit words (as there are 2 32 bit words in the
8260's interrupt manager) and then rather than giving the value of the
structure to splraise(), give it the address.  cpl now becomes a
pointer, and the correct mask is loaded from that structure pointed to
by cpl.

I'm almost tempted to just hack around all of this and setup code such
that all interrupts are blocked until the currently running handler
completes.  The 8260's interrupt manager automatically queues all
interrupts and delivers them one at a time in priority order, where the
priorities may be adjusted by the software through the setting of a few
registers.  The nice thing is that the IRQ number is stored in a
register during the interrupt, and may be read out, without needing to
do a bit-search across the word to locate the first IRQ pending.

What's everyone elses take on the last two paragraphs?  Is my
understanding of the NetBSD interrupt model correct?

--
Shawn.