From: Tom Zanussi on
On Mon, 2010-04-19 at 16:04 -0400, 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.
>
> I would also like to do just:
>
> echo 'traceoff' > events/sched/sched_wakeup/filter
>
> to disable tracing every time the event is hit.
>
> Perhaps you can just add a call back where the kernel could register
> something to be called if a command is used in the filter.
>
> register_event_command("traceoff", trace_off_cb);
>
> where the trace_off_cb is a function that is called by the event if the
> traceoff command is hit. This would allow other commands to be added
> later.
>
> Would something like this be doable, I was looking at the code, and it
> certain looks feasible, but it would take me longer to implement it than
> it would you :-)
>

If this was all you wanted to do, I think it would be pretty simple to
just pluck off the 'if' and the 'command' from the ends of the filter
string and hook it up to the command callback.

If neither of those were present and you just had a bare filter string,
it would invoke the 'default command' which would do just what it does
now - log it into the trace buffer.

Putting just the 'command' into the filter would also work - it would
always match and unconditionally invoke the command.

The 'if' syntax kind of limits it to a single command per filter though.
If you kept it as an expression e.g.

traceoff(pid == 1234)

or to make it more readable

traceoff_if(pid == 1234)

then you could maybe do things like nesting to fire multiple commands
per hit:

traceoff(logevent((pid == 1234))

That's seems like kind of a stretch, though, and implies chaining.

Maybe something like:

traceoff,logevent if (pid == 1234)

would be more intuitive (or not).

Anyway, all of these would be pretty easily doable by simply
preprocessing the filter string. Adding it properly to the parser would
be a little more work, and probably the way to go especially considering
that this wouldn't be the last feature that would be added ;-)

But I think Frederic's idea of decoupling the filters from the triggers
is probably better anyway, and it also allows for different triggers to
be associated with different filters, which the above can't do...

Tom

> Thanks,
>
> -- Steve
>
>

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