Michael R. Zucca wrote:
> >Scott also has mentioned using something like how the i386 does interupts.
> >I don't understand it, so I can't comment. :-)
> 
> I'm not sure I understand either. Scott?
> 
> Well, there's always the Quadra alternate interrupt priority that makes
> the interrupt scheme more germaine to UNIX. The trick is finding the
> appropriate bit to flip.

One thing that was mentioned was having all of the upper-level interrupt
handlers check for the presence of lower-priority interrupts just after
finishing their processing and before returning.  If a clock interrupt was
pending, the higher-priority handler could call the clock interrupt
handler and then return after the clock interrupt handler had returned (if
that's not too confusing ;-)  I think this is more or less how it was
explained the last time this issue came up.

I suppose another way to do it (if this is not already done), and perhaps
the way that i386 does it, is to have the hardware interrupt handlers
perform the absolute minimum necessary to service the interrupt and then
schedule a software interrupt at some point in the future to finish off
processing (of course, we could already be doing this, I haven't looked
too deeply into how our interrupt handling occurs).  Likewise, I don't
know what the effects of this are on performance.  I also am not entirely
sure what kind of locking might be necessary in order to prevent
corruption of certain data structures when the hardware interrupt handler
is called while the software interrupt handler is currently running....oh
well.

Fun with interrupts is project for another day ;-)

Later.

-- 
Colin Wood                                 cwood@ichips.intel.com
Component Design Engineer - PMD                 Intel Corporation
-----------------------------------------------------------------
I speak only on my own behalf, not for my employer.