Re: [PATCH 3/9 - v2][RFC] tracing: Remove per event traceregistering

From: Steven Rostedt
Date: Fri May 07 2010 - 15:08:36 EST


On Fri, 2010-05-07 at 20:01 +0200, Frederic Weisbecker wrote:
> On Fri, May 07, 2010 at 10:54:38AM -0400, Mathieu Desnoyers wrote:

> The second is this extra parameter passed whether or not it is needed.
> And although we suppose it is safe, I don't feel comfortable with it.
> So if we can find a more proper way to avoid it, I'm all for it.

Now I'm making the extra parameter mandatory for all tracepoint
probes. ;-)

But this time, it will be at the start not the end.

void probe(void *data, proto);


Unfortunately we can't avoid it. In order to remove the extra code
(registering and unregistering) and even share the probe among several
events, we need a way to pass the data to the probe to let the probe
know what event it is dealing with (to put in the event id into the
buffer, to let the tracer output code know what event this data is for).

The current method is that only the proto that the tracepoint uses is
passed to the probe. This gives us no way to add any more information.

This new method allows data to be assigned at probe register, and the
probe gets this data as the first parameter.

The register_* functions will still do typechecking of the probes, they
just add the "void *" at the beginning.

Actually, here is a place that I can see where Mathieu's check does come
in handy. If we add the check test to each probe, and the tracepoint
proto changes, it will flag it.

Mathieu, you've been explaining this wrong ;-)

I'm not worried about changes to ftrace.h breaking things. I'm worried
about changes to tracepoint.h breaking ftrace.h. This is where your
check comes in. As I change the void *data from the end to the start,
I'm nervous about catching all the probes that are registered this way.
(ftrace events, syscalls, kprobes, and perf)

-- 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/