On Mon, Apr 19, 2010 at 04:44:06PM -0400, Steven Rostedt wrote:
quoted text
> 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
> 
> 


The problem with having triggers defined in the filter file is that
you couldn't set a normal filter plus a trigger.

That said a filter itself could be a trigger.

if (cond) filter

This is going to break some ABI though.

In fact having one file per trigger type is going to make the
things much easier if you don't want to encumber with syntax parsing,
and just reuse the filtering code as is with very few modification.
This is going to be also easier for the users as they don't have to
remember the syntax or the available triggers.

Say you are in an event directory:

$ ls triggers/

filter
tracing_off
tracing_on
dump_trace

$ echo "(a == 1 && b == 2)" > tracing_off

So in the above example, you just reuse the filtering code,
no need to parse an if or a command.
The filter becomes a command. I've listed it in the triggers
directory but this just to express the fact it can be treated
like whatever trigger command, this is just an implementation
POV. In fact we can just keep it in the event directory.


--
unsubscribe notice
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/