On Tue, Jan 30, 2001 at 03:44:15PM -0800, David Querbach wrote:
> Actually, I think it's even worse than that.  If I'm not mistaken, the prep,
> bebox, and macppc ports each disable all external interrupts when running
> any interrupt handler, whether immediately upon receipt or later in
> do_pending_int().  This includes even software interrupt handlers.
> 
> If so, this seems overly cautious, and detrimental to interrupt latency. 
> Could someone who knows the truth please comment?

Actually, the bebox (at least--not sure about the others) masks
interrupts, but doesn't actually disable the external interrupts
while in the interrupt handler, so any other interrupts that arrive
will be deferred to the do_pending_int() processing.

With a good OpenPIC (like the EPIC in the MPC 8240) you should be
able to do better--assuming you don't have multiple interrupt
sources tied to one interrupt input.

For the softint processing, you probably do want to have interrupts
re-enabled, but this code obviously doesn't do that.  This would be
pretty straight-forward to do.

For external and pending interrupts, you (at a minimum) want to block
the interrupts of a lower priority than the interrupt that you're
processing at a given time.  However, splhigh() is a superset of those
and should be safe to use at the expense of a higher average latency.

On your original question, it's my opinion that hard serial interrupts
should be blocked by splhigh() and splserial() should be just under
splhigh() (on most platforms with short serial FIFOs ;-).  In that
case, if you don't want to make drastic changes, there should be an
spl-level defined to block everything but serial interrupts and that
should be used instead of splhigh() in ext_intr().

-allen

-- 
 Allen Briggs                     briggs@wasabisystems.com
 http://www.wasabisystems.com/    Quality NetBSD CDs, Sales, Support, Service