Messages in this thread | | | Subject | Re: request to add trace off and trace on with events | From | Steven Rostedt <> | Date | Mon, 19 Apr 2010 19:59:26 -0400 |
| |
On Tue, 2010-04-20 at 01:04 +0200, Frederic Weisbecker wrote:
> > # ls event/sched/sched_switch/triggers/tracing_off > > filter enable > > > > ? > > > That would be perhaps an overkill.
Perhaps, but I was also thinking of having triggers in the system level. That way all events below it can trigger.
> Having a filter inside means it's on, otherwise it's off. > > > > > > > > > > > > > > > > This could also allow a user to do: > > > > > > > > echo "(a > 100)" > tracing_on > > > > echo "(a < 100)" > tracing_off > > > > > > > > > Yeah :) > > > But if the scope of the "tracing off" is only for this event, then > > > rather use: > > > > > > echo "(a < 100)" > filter > > > > > > You could have tracing_off/on that have this event scope and > > > tracing_off/on_all for a global tracing scope. > > > > The two are not equivalent. In fact, just enabling a trigger does not > > mean that the event itself will be traced. > > > Yeah, the enable file would first need to be activated before any > trigger to take effect on the event, just like filters. > > In fact I was thinking of tracing_on/tracing_off as kinds of > local pause/resume. > > And tracing_on_global/tracing_off_global would act like what does > /debug/tracing/tracing_on: something that disables every tracing. > > But of course, before any of these conditional triggers to be > evaluated, you need to enable the corresponding event.
We could have a "trace_event_on" and "trace_event_off" trigger that only enables the event when hit.
Actually, we can have these triggers enable other events, or make dynamic triggers:
echo "enable_sched_switch" > events/sched/sched_wakeup/trigger/activate
or something similar.
-- Steve
| |