> However, there are just too many broken machines out there that do not
> support the above (obviously correct) semantics very well. A lot of
> hardware has a notion of interrupt priorities, and a "higher-priority"
> interrupt will block all lower-priority interrupts. As a result, even
> though the Linux approach to interrupts is supposed to be simple and
> clean, hardware considerations still mean that we do _not_ want to spend
> much time inside the interrupt handler.
You could get closer to this behaviour by providing an equivalent to a
software interrupt with every hardware interrupt, allowing the hardware
handler to ack the irq, then fall straight through to the softirq bit
for that driver and/or device.
This is almost like high priority real-time threads (irq handlers),
slightly lower (irq handler after ack and local sti()), yet lower ones
(bottom halves), then the normal processes.
So many levels suggests maybe there's a way to abstract these different
levels as if they were runnable processes waiting to be triggered,
without any context. And then consider what kind of scheduling is
really required to keep everything fair in the event of overruns, and
where the higher levels would like to communicate directly
(aka. fastroute without NET_BH, timers at higher priorities).
I wouldn't be surprised if there's a way to do this scheduling quite
generally (much like the normal process scheduling) but that's also as
fast as what we have now in the normal cases. Consider how simple
testing for pending bottom-halves is in ret_from_syscall.
-- Jamie
-
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/