All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Zanussi <tom.zanussi@linux.intel.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: masami.hiramatsu.pt@hitachi.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v9 04/10] tracing: Add 'snapshot' event trigger command
Date: Fri, 13 Sep 2013 16:10:19 -0500	[thread overview]
Message-ID: <1379106619.1558.45.camel@empanada> (raw)
In-Reply-To: <20130913160100.30686d60@gandalf.local.home>

On Fri, 2013-09-13 at 16:01 -0400, Steven Rostedt wrote:
> On Sat,  7 Sep 2013 10:29:00 -0500
> Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> 
> 
> > --- a/kernel/trace/trace_events_trigger.c
> > +++ b/kernel/trace/trace_events_trigger.c
> > @@ -696,6 +696,74 @@ static struct event_command trigger_traceoff_cmd = {
> >  	.get_trigger_ops	= onoff_get_trigger_ops,
> >  };
> >  
> > +static void
> > +snapshot_trigger(struct event_trigger_data *data)
> > +{
> > +	tracing_snapshot();
> > +}
> 
> If CONFIG_TRACER_SNAPSHOT is not defined, then we should not bother
> implementing the snapshot trigger. This should be encapsulated around
> ifdefs.

OK, I guess I was just trying to avoid the ifdef since
tracing_snapshot() is already ifdef'ed out (but with a WARN_ONCE()) if
CONFIG_TRACER_SNAPSHOT isn't defined.

I agree though, it would be better to just ignore all the snapshot
trigger code if that's the case.  Same for the stacktrace trigger,
though as much as I hate to put big ifdefs in the main code...

> 
> > +
> > +static void
> > +snapshot_count_trigger(struct event_trigger_data *data)
> > +{
> > +	if (!data->count)
> > +		return;
> > +
> > +	if (data->count != -1)
> > +		(data->count)--;
> > +
> > +	snapshot_trigger(data);
> > +}
> > +
> > +static int
> > +register_snapshot_trigger(char *glob, struct event_trigger_ops *ops,
> > +			  struct event_trigger_data *data,
> > +			  struct ftrace_event_file *file)
> > +{
> > +	int ret = register_trigger(glob, ops, data, file);
> > +
> > +	if (ret > 0)
> > +		ftrace_alloc_snapshot();
> > +
> > +	return ret;
> > +}
> > +
> > +static int
> > +snapshot_trigger_print(struct seq_file *m, struct event_trigger_ops *ops,
> > +		       struct event_trigger_data *data)
> > +{
> > +	return event_trigger_print("snapshot", m, (void *)data->count,
> > +				   data->filter_str);
> > +}
> > +
> > +static struct event_trigger_ops snapshot_trigger_ops = {
> > +	.func			= snapshot_trigger,
> > +	.print			= snapshot_trigger_print,
> > +	.init			= event_trigger_init,
> > +	.free			= event_trigger_free,
> > +};
> > +
> > +static struct event_trigger_ops snapshot_count_trigger_ops = {
> > +	.func			= snapshot_count_trigger,
> > +	.print			= snapshot_trigger_print,
> > +	.init			= event_trigger_init,
> > +	.free			= event_trigger_free,
> > +};
> > +
> > +static struct event_trigger_ops *
> > +snapshot_get_trigger_ops(char *cmd, char *param)
> > +{
> > +	return param ? &snapshot_count_trigger_ops : &snapshot_trigger_ops;
> > +}
> > +
> > +static struct event_command trigger_snapshot_cmd = {
> > +	.name			= "snapshot",
> > +	.trigger_type		= ETT_SNAPSHOT,
> > +	.func			= event_trigger_callback,
> > +	.reg			= register_snapshot_trigger,
> > +	.unreg			= unregister_trigger,
> > +	.get_trigger_ops	= snapshot_get_trigger_ops,
> > +};
> > +
> >  static __init void unregister_trigger_traceon_traceoff_cmds(void)
> >  {
> >  	unregister_event_command(&trigger_traceon_cmd);
> > @@ -726,5 +794,11 @@ __init int register_trigger_cmds(void)
> >  		return ret;
> >  	}
> >  
> > +	ret = register_event_command(&trigger_snapshot_cmd);
> > +	if (WARN_ON(ret < 0)) {
> > +		unregister_trigger_traceon_traceoff_cmds();
> 
> If the snapshot trigger fails, why remove the traceon_traceoff trigger
> if it succeeded? Is there some dependency that we should be worried
> about?
> 
> Or is this just saying "if once trigger fails, they all fail!"?
> 

Right, that's all its saying, there's no dependency.  I guess it would
be fine to just continue with whatever triggers did/will register
successfully - the WARN_ON() will show the failure for a given trigger,
no need to disable everything.

Tom

> -- Steve
> 
> > +		return ret;
> > +	}
> > +
> >  	return 0;
> >  }
> 



  reply	other threads:[~2013-09-13 21:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-07 15:28 [PATCH v9 00/10] tracing: trace event triggers Tom Zanussi
2013-09-07 15:28 ` [PATCH 01/10] tracing: Add support for SOFT_DISABLE to syscall events Tom Zanussi
2013-09-07 15:28 ` [PATCH v9 02/10] tracing: Add basic event trigger framework Tom Zanussi
2013-09-07 15:28 ` [PATCH v9 03/10] tracing: Add 'traceon' and 'traceoff' event trigger commands Tom Zanussi
2013-09-07 15:29 ` [PATCH v9 04/10] tracing: Add 'snapshot' event trigger command Tom Zanussi
2013-09-13 20:01   ` Steven Rostedt
2013-09-13 21:10     ` Tom Zanussi [this message]
2013-09-14  1:05       ` Steven Rostedt
2013-09-07 15:29 ` [PATCH v9 05/10] tracing: Add 'stacktrace' " Tom Zanussi
2013-09-07 15:29 ` [PATCH v9 06/10] tracing: Add 'enable_event' and 'disable_event' event trigger commands Tom Zanussi
2013-09-07 15:29 ` [PATCH v9 07/10] tracing: Add and use generic set_trigger_filter() implementation Tom Zanussi
2013-09-07 15:29 ` [PATCH v9 08/10] tracing: Update event filters for multibuffer Tom Zanussi
2013-09-07 15:29 ` [PATCH v9 09/10] tracing: Add documentation for trace event triggers Tom Zanussi
2013-09-07 15:29 ` [PATCH v9 10/10] tracing: Make register/unregister_ftrace_command __init Tom Zanussi
2013-09-09  6:39 ` [PATCH v9 00/10] tracing: trace event triggers Masami Hiramatsu

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=1379106619.1558.45.camel@empanada \
    --to=tom.zanussi@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=rostedt@goodmis.org \
    /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.