Interrupt API change

Scott Long scottl at
Fri Jan 9 11:01:20 PST 2004


At the September DevSummit, Peter Wemm proposed changing the device
driver API so that interrupt routines return an INT instead of a VOID.
The primary purpose of this is two-fold.  The first is so interrupt
handlers can communicate back to the low-level interrupt routines
whether or not they were able to handle the interrupt.  Heuristics
can then be built on this information to better detect things like
interrupt storms.  This change also paves the way for the proposal
to make interrupts be multi-tiered.  The first level interrupt handler
can relay back whether it wants the second-level handler to be run
(similar to filter interrupt handlers in Max OS X).

I'm not ready to go in the multi-level interrupt direction just yet,
but changing the API now will help that later if needed.  The change
will consist of changing the driver_intr_t typedef in /sys/sys/bus.h
to return an int, and then doing a sweep of the entire tree.  I expect
no functional change from this right now.

Future plans for the interrupt API include the possiblity of mutli-
level interrupt handlers, and expanding the API to handle message
interrupts.  Message interrupts are like what is found in the
PCI/PCI-X/PCI-Express specs under 'Message Signaled Interrupts'.
Under MSI, a device sends a data message over the bus to signal an
interrupt instead of raising and INTx line.  The interrupt controller
sees this message and turns it into an interrupt vector for the
CPU.  Since MSI allows devices to define more than one message, drivers
can in turn have multiple, specific interrupt handlers.  Our interrupt
API has no concept of this, and will need to be enhanced to support
the idea of negotiating the number of allowed messages, and then
registering the appropriate handler for each message.  I've not decided
exactly how to do this yet, so anyone with knowledge of the PCI specs
is welcome to give input.


More information about the freebsd-arch mailing list