All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizf@cn.fujitsu.com>
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>,
	Mathieu Desnoyers <compudj@krystal.dyndns.org>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Masami Hiramatsu <mhiramat@redhat.com>,
	Christoph Hellwig <hch@lst.de>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Subject: Re: [PATCH 02/10][RFC] tracing: Let tracepoints have data passed to tracepoint callbacks
Date: Tue, 27 Apr 2010 17:08:29 +0800	[thread overview]
Message-ID: <4BD6A98D.6010706@cn.fujitsu.com> (raw)
In-Reply-To: <20100426200241.631945432@goodmis.org>

Steven Rostedt wrote:
> From: Steven Rostedt <srostedt@redhat.com>
> 
> This patch allows data to be passed to the tracepoint callbacks
> if the tracepoint was created to do so.
> 
> If a tracepoint is defined with:
> 
> DECLARE_TRACE_DATA(name, proto, args)
> 
> Then a registered function can also register data to be passed
> to the tracepoint as such:
> 
>   DECLARE_TRACE_DATA(mytracepoint, TP_PROTO(int status), TP_ARGS(status));
> 
>   /* In the C file */
> 
>   DEFINE_TRACE(mytracepoint, TP_PROTO(int status), TP_ARGS(status));
> 
>   [...]
> 
>        trace_mytacepoint(status);
> 
>   /* In a file registering this tracepoint */
> 
>   int my_callback(int status, void *data)
>   {
> 	struct my_struct my_data = data;
> 	[...]
>   }
> 
>   [...]
> 	my_data = kmalloc(sizeof(*my_data), GFP_KERNEL);
> 	init_my_data(my_data);
> 	register_trace_mytracepoint_data(my_callback, my_data);
> 
> The same callback can also be registered to the same tracepoint as long
> as the data registered is the same. Note, the data must also be used
> to unregister the callback:
> 
> 	unregister_trace_mytracepoint_data(my_callback, my_data);
> 
> Because of the data parameter, tracepoints declared this way can not have
> no args. That is:
> 
>   DECLARE_TRACE_DATA(mytracepoint, TP_PROTO(void), TP_ARGS());
> 
> will cause an error, but the original DECLARE_TRACE still allows for this.
> 
> The DECLARE_TRACE_DATA() will be used by TRACE_EVENT() so that it
> can reuse code and bring the size of the tracepoint footprint down.
> This means that TRACE_EVENT()s must have at least one argument defined.

We have to define at least on argument in TRACE_EVENT() even without
this patch, otherwise it'll cause compile error while expanding the
macros.

> This should not be a problem since we should never have a static
> tracepoint in the kernel that simply says "Look I'm here!".
> 

We do have such a tracepoint. ;)

That is trace_power_end, and it uses a dummy argument merely for
passing compilation.


  reply	other threads:[~2010-04-27  9:06 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 [this message]
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
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=4BD6A98D.6010706@cn.fujitsu.com \
    --to=lizf@cn.fujitsu.com \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=compudj@krystal.dyndns.org \
    --cc=fweisbec@gmail.com \
    --cc=hch@lst.de \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.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.