Another one i would recommend if this is making its way to the base
linux kernel is that we should ask the irq handlers to return some
value so that the kernel could know who took this interrupt. so if 2
devices are sharing an interrupt, and if the kernel calls the first
registered handler, and it knew its device interrupted, then on
returning from the irq handler if we return 1 to indicate this
interrupt is consumer, we possibly dont need to send this to all of
the registered handlers?
Life gets a bit more tricy on the ISA bus, because interrupts are edge
triggered. Suppose while you're servicing device #1, device #2 signals
an interrupt. If you don't check device #2 before you exit, the IRQ is
still high, and since interrupts are edge triggered, that IRQ channel
won't cause any more interrupts, and device #1 and #2 will *both* be
dead in the watter.
So yes, having the irq handlers return a signal indicating whether they
serviced the device is useful, but if you're going to share interrupts
that are edge triggered, what you have to do is repeatedly call *all* of
them over and over again until they all report that all of the devices
don't need servicing, and hope/pray you don't hit a race condition where
a device became ready while you were checking the other devices in the
chain. (This is why I don't recommend using more than 16 serial ports
on a single IRQ, at least when using an ISA bus. The serial driver has
watchdog timers to recover if the interrupt line gets wedged, but
characters will likely still get lost unless the UART's have very deep
FIFO's.)
That's in fact how the serial driver supports multiple serial ports
sharing a single IRQ, at least on an ISA bus. On a saner bus
architecture, where interrupts are level-triggered, this is much less of
an issue --- although there's a tradeoff; if a device driver is buggy
and doesn't know how to make its interrupt service routine clear
whatever condition is causing the device to assert an interrupt, the
system will lock up.
So yes, having the irq handlers return an indication of whether they
serviced the device is useful, but *how* that indication gets used may
have to change depending the bus architecture.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/