Messages in this thread | | | Subject | Re: [patch 3/4] genirq: add a quick check handler | From | Sven-Thorsten Dietrich <> | Date | Thu, 05 Mar 2009 11:59:09 -0800 |
| |
On Sat, 2009-02-28 at 17:24 -0500, Christoph Hellwig wrote: > I really disagree with the notation of the pre-handler. Instead of > adding an additional pre handler method you should add a new threadfn > method. The handler could just as now handle/not handle the interrupt, > or as a third option defer it to the thread. That makes the different > semantics a lot clearer, and means ->handler and ->threadfn both have > very well defined contexts, instead of sometimes calling ->handler > sometimes from irq and sometimes from thread context. This also > makes it much easier for complex hardware that might have simple and > fast interrupts that it may want to handle directly from hardirq context > in just a couple of cycles or complex interrupts that might be deferred > to process context. >
Most of the IRQ handler, whether run in a thread or IRQ context, will be the same code - so what you are proposing would have to eliminate code duplication as well as heavy runtime branching overhead.
Ultimately, no matter how its done, the concept of disabling IRQ assert at the device level, rather than the apic level, is the optimal "correct" implementation.
Formulating that into the code, as Thomas proposed with the quickcheck, supplies structural demarcation for semi as well as software design.
Things just get quite ugly - as-is- when you try to add runtime thread enable and disable.
Sven
| |