Subject: Re: request to add trace off and trace on with events
From: Steven Rostedt <rostedt@goodmis.org>
Reply-To: rostedt@goodmis.org
To: Tim Bird <tim.bird@am.sony.com>
Cc: Tom Zanussi <tzanussi@gmail.com>, Ingo Molnar <mingo@elte.hu>,
       Frederic Weisbecker <fweisbec@gmail.com>,
       Thomas Gleixner <tglx@linutronix.de>,
       Chase Douglas <chase.douglas@canonical.com>,
       LKML <linux-kernel@vger.kernel.org>
In-Reply-To: <4BCCBF6D.3030105@am.sony.com>
References: <1271707444.10448.12.camel@gandalf.stny.rr.com>
	 <4BCCBF6D.3030105@am.sony.com>
Content-Type: text/plain; charset="ISO-8859-15"
Organization: Kihon Technologies Inc.
Date: Mon, 19 Apr 2010 16:44:06 -0400
Message-ID: <1271709846.10448.29.camel@gandalf.stny.rr.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1895
Lines: 51

On Mon, 2010-04-19 at 13:39 -0700, Tim Bird wrote:
> On 04/19/2010 01:04 PM, Steven Rostedt wrote:
> > Hi Tom,
> > 
> > Could you add a way to do a call to tracing_on() or tracing_off() via
> > the filters. I would like to do something like:
> > 
> > 
> > echo 'if (pid == 1234) traceoff' > events/sched/sched_wakeup/filter
> > 
> > Where, if the sched_wakeup event is hit with pid == 1234 it will turn
> > tracing off.
> 
> Just a comment on the nomenclature.  In KFT I called
> things like this "triggers".  I'm not sure what other

Yeah, Mathieu calls them triggers too. But if you do, I'm fine with
calling them that as well.

> tracing systems call them.  I'm a little worried about
> overloading the filtering abstraction with trigger
> semantics.  (I like the idea of triggers, but it might
> be better to control them with another pseudo-file for
> clarity.)
> 
> I suppose both are a form of conditional execution.
> Filtering has an implicit action of either 'trace this'
> or 'don't trace this', while triggering usually has
> an action, often explicit, to start or stop tracing.
> However, since they both use the conditional testing,
> it might be a pain to reproduce this code for a different
> pseudo-file.

I thought about a separate file, but I like the idea of having control
over them. We could add a "trigger" file too, but I'm not sure if that
would be any clearer.

If we add a trigger file, then the filter can be separate, and we just
trigger the trigger if the filter passes.

This may be better, because then the triggers do not mess with the
filtering code, and I can add it without modification to Tom's code.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/