lkml.org 
[lkml]   [2009]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-03-24 21:55    [W:0.097 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site