All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	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>,
	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 2/9 - v2][RFC] tracing: Let tracepoints have data?passed to tracepoint callbacks
Date: Fri, 7 May 2010 11:30:35 -0400	[thread overview]
Message-ID: <20100507153035.GA15267@Krystal> (raw)
In-Reply-To: <1273245338.22438.168.camel@gandalf.stny.rr.com>

* Steven Rostedt (rostedt@goodmis.org) wrote:
> On Fri, 2010-05-07 at 11:08 -0400, Mathieu Desnoyers wrote:
> 
> > > > Can you show me where the C standard says it is safe to do so ?
> > > 
> > > No, but it seems safe in the kernel ;-)
> > 
> > The use of "seems" here does not give me a warm feeling of safety. ;)
> 
> Right, which is why I added the below.
> 
> > 
> > > 
> > > But that said. There is another option that will conform to this, and
> > > that is to add flags to registering tracepoints. I already wrote a patch
> > > for this in trying to do some other work (that I threw away).
> > > 
> > > 
> > > So here's the proposal.
> > > 
> > > Change struct tracepoint_func to...
> > > 
> > > struct tracepoint_func {
> > > 	void *func;
> > > 	void *data;
> > > 	unsigned int flags;
> > > };
> > > 
> > > 
> > > The flags is set when registered. If a function is registered with data,
> > > then the flags field will be set. Then the calling of the function can
> > > be:
> > > 
> > > 	if ((it_func_ptr)->flags & TP_FL_DATA)
> > > 		((void(*)(proto, void *))(it_func)(args, __data);
> > > 	else
> > > 		((void(*)(proto))(it_func)(args);
> > > 
> > > This would comply with the C standard.
> > 
> > This would also add a branch on the tracing fast path, which I would like to
> > avoid. Why can't we simply change all prototypes to take an extra void *__data
> > parameter instead ?
> 
> I'm fine with making the data parameter mandatory with all tracers. Thus
> the call back must require it. I would then move the data parameter from
> the end to the beginning.
> 
> So a tracepoint with proto, will have a callback:
> 
> 	void callback(void *data, proto);
> 
> I'm fine with forcing all callbacks to include a data parameter if you
> are. This would also make the changes simpler.

Yes, I am all for it.

As for the extra type checking, it is basically just trying to force you to
generate matching caller-callee prototypes in your CPP macros. The goal is
really to check that the data parameter type match in both the caller and
callee. I see that as a mean to make sure nobody is going to try to take
shortcuts by playing with the callback types in the "undefined behavior" zone of
the C standard in future TRACE_EVENT() modifications.

Thanks,

Mathieu

> 
> -- Steve
> 
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2010-05-07 15:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-07 12:40 [PATCH 2/9 - v2][RFC] tracing: Let tracepoints have data passed to tracepoint callbacks Steven Rostedt
2010-05-07 14:39 ` [PATCH 2/9 - v2][RFC] tracing: Let tracepoints have data?passed " Mathieu Desnoyers
2010-05-07 14:55   ` Steven Rostedt
2010-05-07 15:08     ` Mathieu Desnoyers
2010-05-07 15:15       ` Steven Rostedt
2010-05-07 15:30         ` Mathieu Desnoyers [this message]
2010-05-07 15:45           ` Steven Rostedt
  -- strict thread matches above, loose matches on Subject: below --
2010-05-04  3:40 [PATCH 0/9 - v2][RFC] tracing: Lowering the footprint of TRACE_EVENTs Steven Rostedt
2010-05-04  3:40 ` [PATCH 2/9 - v2][RFC] tracing: Let tracepoints have data passed to tracepoint callbacks Steven Rostedt
2010-05-07  3:52   ` Frederic Weisbecker
2010-05-07 14:09     ` Steven Rostedt
2010-05-07 18:06       ` Frederic Weisbecker
2010-05-07 19:10         ` Steven Rostedt

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=20100507153035.GA15267@Krystal \
    --to=mathieu.desnoyers@efficios.com \
    --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.