Re: Interrupt handlers in NetBSD 5.0

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> No...just that it's device-specific.  That is, instead of telling
>> the OS or the interrupt routing hardware to ignore the interrupt,
>> you need to tell the device to stop generating it.
> If you could forward that message to the hardware engineers making
> those chips, that they really need to add a global interrupt disable
> bit, then I would be fine.

Heh.  The hardware I've looked at always has some small number of
interrupt-request-enable bits, often one, but of course I've seen only
a comparatively small fraction of the hardware out there.

If you're trying to build a driver for a device that doesn't have an
easy way to shut up interrupts until they get serviced, you likely will
have to do more than you might wish in the hard interrupt routine.
Sucks, but that's life with non-ideal hardware.  (Unless, of course,
you're willing to use MD facilities and are lucky enough to be using a
platform that has them.)

> I would have hoped that there was a machine independent solution for
> this, how to mask an interrupt vector in the OS.

Yes, it would be nice.  But too much hardware simply can't do it, PCI
being perhaps the commonest example.  (PCI has only four interrupt
lines; with more than four devices behind a bus, perforce at least one
line must be shared.)

> BTW: What is the preferred mechanism to exclude an interrupt handler
> from running?  In NetBSD 4.0 you could use spl_net() and now you use
> ???

Depends on exactly what you want.  Even pre-5.x, spl*() affects only
the CPU you execute it on; on multiprocessor machines it won't lock out
other CPUs.  In particular, spl*() cannot be depended on to block an
interrupt unless you're sure you're running on the CPU that will handle
the interrupt.

This makes device driver locking more complicated, yes.  That's life
with SMP; unless you're willing to give up working in multiprocessor
kernels, you'll need to deal with it. :-/

> Thanks for sharing some insight into how NetBSD 5.0 works.

What I said was more in the nature of "the kernel _can't_ do this,
regardless of OS rev, and here's why"; I actually know very little
about 5.0.  For exmaple, you may note I didn't give any details for how
to interlock between a hard interrupt handler and other CPUs; that's
because I don't know those details.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B