Messages in this thread | | | Date | Tue, 24 Mar 2009 21:51:20 +0100 | From | Ingo Molnar <> | Subject | Re: [patch 2/9] LTTng instrumentation - irq |
| |
* Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> If we want to do this logically, without thinking about tracer > performance impact, we could/should do : > > trace_irq_entry(irqno, pt_regs) > for_each_handler() { > trace_irq_handler_entry(action) > action->handler() > trace_irq_handler_exit(ret) > } > trace_irq_exit(retval)
Not really.
As i said, the handler invocation should be thought of separately from vectored IRQs. A device IRQ handler can be invoked in a number of non-vectored ways: it can be called in an IRQ thread for example. (there are other invocation modes possible too)
For IRQ vectors, the 'retval' makes little sense - so the exit event can be left out.
Which leaves us with what i suggested: to add an IRQ vector entry event on top of Jason's (already integrated) patches.
Hm?
Ingo
| |