From mboxrd@z Thu Jan  1 00:00:00 1970
From: mingo@elte.hu (Ingo Molnar)
Date: Tue, 24 Mar 2009 21:51:20 +0100
Subject: [ltt-dev] [patch 2/9] LTTng instrumentation - irq
In-Reply-To: <20090324201146.GA4350@Krystal>
References: <20090324155625.420966314@polymtl.ca>
	<20090324160148.080628193@polymtl.ca>
	<20090324173354.GC3129@redhat.com> <20090324175049.GC31117@elte.hu>
	<20090324175750.GE3129@redhat.com> <20090324191252.GA11665@elte.hu>
	<20090324201146.GA4350@Krystal>
Message-ID: <20090324205120.GB24320@elte.hu>


* Mathieu Desnoyers <mathieu.desnoyers at 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