That is how almost every other operating system that uses polled interrupts
does it. The handler returns one defined value if they didn't handle it and
a different value if it was handled.
I was surprised that Linux didn't have the driver poll routine return a
value.
Before we redesign the interrupt handling behavior, I would like to see some
information indicating how long the poll chain gets. Determine what (if any)
the measurable performance benefits are before considering the change.
That's because normally the poll chain doesn't get very long at all. In
fact, for a long time you didn't share interrupt channels; a device got
an interrupt channel all to itself.
If you are changing the interrupt scheme though, you should really think
about putting support for vectored interrupts in. This would help the VMEbus
people. For those who may not know, vectored interrupts are interrupts where
you are immediately given an interrupt vector which can be used to determine
which handler to call. No need to poll various drivers to figure out who is
asserting the interrupt.
That's not unlike IRQ 3 vs IRQ 4 vs IRQ 5 in the Intel world. The only
difference between that and the VMEbus is that there aren't enough
interrupts on a typical PC, which is what forced some devices to try to
share interrupts on a single interrupt channel (and which forces the
polling behaviour).
- 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/