One problem that can confront an operating system kernel is that of
"screaming" devices - hardware which continually raises interrupts, but for
which there is no driver to tell it to shut up. If the offending hardware
is yanking on an interrupt line which is not otherwise in use, the kernel
can quickly disable that line and be done with the problem. If, however,
the interrupt line is in use in a shared mode, there is (in kernels through
2.5.68) no way for the kernel to know that nobody is dealing with the loud
device. All it can do is pass an interrupt request to the registered
handlers and hope for the best.
Of course, there is no need for things to be that way; each device driver
knows whether it handled a specific interrupt or not. So all that's needed
is for the drivers to communicate that information back to the kernel. The
2.5.69 kernel does exactly that - thanks to a
patch by Linus - at the cost of breaking every driver which registers
an interrupt handler.
Interrupt handlers no longer return void; instead, they must
return an irqreturn_t value (adding typedefs to the kernel is OK
when Linus does it). The values are IRQ_HANDLED if the driver
recognized the interrupt or IRQ_NONE if the interrupt was not for
one of the driver's devices. The IRQ_RETVAL(handled) macro can
also be used; the handled parameter should be nonzero if the
interrupt was handled in the driver.
With this change, the kernel can tell whether a particular device is being
handled or not. As of this writing, the "fix the drivers" effort is in
full swing; by the time 2.5.69 is released, most of the (in-tree) drivers
should be working again. At least, with regard to the interrupt change.
to post comments)