Re: [PATCH 02/11] tracing: Introduce TRACE_EVENT_INJECT

From: Steven Rostedt
Date: Fri Feb 05 2010 - 10:07:40 EST


On Fri, 2010-02-05 at 15:53 +0100, Peter Zijlstra wrote:
> On Fri, 2010-02-05 at 09:47 -0500, Steven Rostedt wrote:
> > On Wed, 2010-02-03 at 10:14 +0100, Frederic Weisbecker wrote:
> > > TRACE_EVENT_INJECT macro is the same as TRACE_EVENT but takes one
> >
> > > #undef DEFINE_EVENT
> > > #define DEFINE_EVENT(template, call, proto, args) \
> > > static void ftrace_profile_##call(proto) \
> > > diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> > > index 189b09b..5c75cc7 100644
> > > --- a/kernel/trace/trace_events.c
> > > +++ b/kernel/trace/trace_events.c
> > > @@ -142,6 +142,9 @@ static int ftrace_event_enable_disable(struct ftrace_event_call *call,
> > > break;
> > > }
> > > call->enabled = 1;
> > > +
> > > + if (call->inject)
> > > + call->inject();
> > > }
> > > break;
> > > }
> >
> > With the proposal I'm suggesting:
> >
> > register_event_command(event, NULL, NULL, inject_me, inject_me, data);
> >
> > The above would do basically what this patch does. When ever the event
> > is enabled or disabled the inject_me function will be called.
> >
> > Would this work?
>
> No, because a dump all inject sucks chunks.

How would it be dumping all?

You need to pick an event to register, not all events will do this.

How is this different than defining a TRACE_EVENT_INJECT()? Now
lock_class_init will always call this inject.

What I am proposing is to add the lock_class_init just as TRACE_EVENT()
and then in a initcall, do:

register_event_command("lock_class_init", NULL, NULL, inject_me,
inject_me, data);

The above would have lock_class_init, when enabled or disabled call
inject_me. Isn't that exactly what the TRACE_EVENT_INJECT() is doing?

I have no qualms about adding lock_class_init, I just don't think we
need another TRACE_EVENT macro, that is very inflexible. I rather
consolidate the macros in ftrace.h than be adding new ones.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/