linux-kernel - Re: request to add trace off and trace on with events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100419212950.GB8811@nowhere>
Date:	Mon, 19 Apr 2010 23:29:52 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Tim Bird <tim.bird@...sony.com>, Tom Zanussi <tzanussi@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Chase Douglas <chase.douglas@...onical.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: request to add trace off and trace on with events

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

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