From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Li Zefan <lizf@cn.fujitsu.com>,
Masami Hiramatsu <mhiramat@redhat.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 04/10][RFC] tracing: Remove per event trace registering
Date: Fri, 30 Apr 2010 17:02:22 -0400 [thread overview]
Message-ID: <20100430210222.GA18071@Krystal> (raw)
In-Reply-To: <1272658477.9739.201.camel@gandalf.stny.rr.com>
* Steven Rostedt (rostedt@goodmis.org) wrote:
> On Fri, 2010-04-30 at 16:07 -0400, Mathieu Desnoyers wrote:
> > * Steven Rostedt (rostedt@goodmis.org) wrote:
> > > On Fri, 2010-04-30 at 15:06 -0400, Mathieu Desnoyers wrote:
> > >
> > > > > If it is possible sure, but that's the point. Where do you add the
> > > > > check? The typecast is in the C code that is constant for all trace
> > > > > events.
> > > >
> > > > You can add the call to the static inline type check directly within the
> > > > generated probe function, right after the local variable declarations.
> > >
> > > Well, one thing, the callback is not going to be the same as the
> > > DECLARE_TRACE() because the prototype ends with "void *data", and the
> > > function being called actually uses the type of that data.
> > >
> > > We now will have:
> > >
> > > DEFINE_TRACE(mytracepoint, int myarg, myarg);
> > >
> > > void mycallback(int myarg, struct mystuct *mydata);
> > >
> > > register_trace_mytracepoint_data(mycallback, mydata)
> > >
> > > There's no place in DEFINE_TRACE to be able to test the type of data
> > > that is being passed back. I could make the calling function be:
> > >
> > > void mycallback(int myarg, void *data)
> > > {
> > > struct mystruct *mydata = data;
> > > [...]
> > >
> > > Because the data is defined uniquely by the caller that registers a
> > > callback. Each function can register its own data type.
> >
> > Yep. There would need to be a cast from void * to struct mystruct *
> > at the beginning of the callback as you propose here. I prefer this cast
> > to be explicit (as proposed here) rather than hidden within the entire
> > function call (void *) cast.
> >
>
> OK, so you prefer that, I don't, but I also don't care, so I could
> easily change it.
>
>
> > > Let me explain this again:
> > >
> > > DECLARE_TRACE(name, proto, args);
> > >
> > > Will call the function like:
> > >
> > > callback(args, data);
> > >
> > > The callback will be at best:
> > >
> > > int callback(proto, void *data);
> > >
> > >
> > > because the data being passed in is not defined yet. It is defined at
> > > the point of the registering of the callback. You can have two callbacks
> > > registered to the same tracepoint with two different types as the data
> > > field.
> > >
> > > So what is it that this check is testing?
> >
> > It's making sure that TRACE_EVENT() creates callbacks with the following
> > signature:
> >
> > void callback(proto, void *data)
> >
> > rather than
> >
> > void callback(proto, struct somestruct *data)
> >
> > and forces the cast to be done within the callback rather than casting
> > the whole function pointer type to void *, assuming types to match. I
> > prefer to leave the cast outside of the tracepoint infrastructure, so we
> > do not obfuscate the fact that an explicit type cast is needed there.
>
> Fine, but I hardly see it as obfuscation. But my question again, even if
> we do change this. What is this test testing? To me, it is checking that
> CPP works.
It's checking that the macros generated compatible call/callback
prototypes, yes. It comes down to using the compiler type-checking to
double-check that the macros are fine.
Thanks,
Mathieu
>
> -- Steve
>
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2010-04-30 21:02 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-26 19:50 [PATCH 00/10][RFC] tracing: Lowering the footprint of TRACE_EVENTs Steven Rostedt
2010-04-26 19:50 ` [PATCH 01/10][RFC] tracing: Create class struct for events Steven Rostedt
2010-04-28 20:22 ` Mathieu Desnoyers
2010-04-28 20:38 ` Steven Rostedt
2010-04-26 19:50 ` [PATCH 02/10][RFC] tracing: Let tracepoints have data passed to tracepoint callbacks Steven Rostedt
2010-04-27 9:08 ` Li Zefan
2010-04-27 15:28 ` Steven Rostedt
2010-04-28 20:37 ` Mathieu Desnoyers
2010-04-28 23:56 ` Steven Rostedt
2010-04-26 19:50 ` [PATCH 03/10][RFC] tracing: Convert TRACE_EVENT() to use the DECLARE_TRACE_DATA() Steven Rostedt
2010-04-28 20:39 ` Mathieu Desnoyers
2010-04-28 23:57 ` Steven Rostedt
2010-04-29 0:03 ` Mathieu Desnoyers
2010-04-26 19:50 ` [PATCH 04/10][RFC] tracing: Remove per event trace registering Steven Rostedt
2010-04-28 20:44 ` Mathieu Desnoyers
2010-04-29 0:00 ` Steven Rostedt
2010-04-29 0:05 ` Mathieu Desnoyers
2010-04-29 0:20 ` Steven Rostedt
[not found] ` <20100429133649.GC14617@Krystal>
2010-04-29 14:06 ` Steven Rostedt
2010-04-29 14:55 ` Mathieu Desnoyers
2010-04-29 16:06 ` Steven Rostedt
2010-04-30 17:09 ` Mathieu Desnoyers
2010-04-30 18:16 ` Steven Rostedt
2010-04-30 19:06 ` Mathieu Desnoyers
2010-04-30 19:48 ` Steven Rostedt
2010-04-30 20:07 ` Mathieu Desnoyers
2010-04-30 20:14 ` Steven Rostedt
2010-04-30 21:02 ` Mathieu Desnoyers [this message]
2010-04-26 19:50 ` [PATCH 05/10][RFC] tracing: Move fields from event to class structure Steven Rostedt
2010-04-28 20:58 ` Mathieu Desnoyers
2010-04-29 0:02 ` Steven Rostedt
[not found] ` <20100429133213.GA14617@Krystal>
2010-04-29 13:50 ` Steven Rostedt
2010-04-26 19:50 ` [PATCH 06/10][RFC] tracing: Move raw_init from events to class Steven Rostedt
2010-04-28 21:00 ` Mathieu Desnoyers
2010-04-26 19:50 ` [PATCH 07/10][RFC] tracing: Allow events to share their print functions Steven Rostedt
2010-04-28 21:03 ` Mathieu Desnoyers
2010-04-26 19:50 ` [PATCH 08/10][RFC] tracing: Move print functions into event class Steven Rostedt
2010-04-28 21:03 ` Mathieu Desnoyers
2010-04-26 19:50 ` [PATCH 09/10][RFC] tracing: Remove duplicate id information in event structure Steven Rostedt
2010-04-28 21:06 ` Mathieu Desnoyers
2010-04-29 0:04 ` Steven Rostedt
2010-04-26 19:50 ` [PATCH 10/10][RFC] tracing: Combine event filter_active and enable into single flags field Steven Rostedt
2010-04-28 21:13 ` Mathieu Desnoyers
2010-04-28 14:45 ` [PATCH 00/10][RFC] tracing: Lowering the footprint of TRACE_EVENTs Masami Hiramatsu
2010-04-28 20:18 ` Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100430210222.GA18071@Krystal \
--to=compudj@krystal.dyndns.org \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=hch@lst.de \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.