Date: Tue, 28 Apr 2009 11:50:39 -0400 (EDT)
From: Steven Rostedt <rostedt@goodmis.org>
To: Tom Zanussi <tzanussi@gmail.com>
cc: LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
       Frederic Weisbecker <fweisbec@gmail.com>,
       Li Zefan <lizf@cn.fujitsu.com>
Subject: Re: [PATCH 0/3] tracing/filters: new event parser
In-Reply-To: <1240905879.6416.118.camel@tropicana>
Message-ID: <alpine.DEB.2.00.0904281149280.8066@gandalf.stny.rr.com>
References: <1240905879.6416.118.camel@tropicana>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2765
Lines: 76


On Tue, 28 Apr 2009, Tom Zanussi wrote:

> This patchset replaces the current event parser hack with a better, more
> extensible version.  See patch 3 for the details on syntax and usage.  
> 
> Basically, instead of defining a filter predicate by predicate as in the
> current version, you now define the whole thing all at once and in
> addition to the current == and != operators, can use >, <, >=, <=,
> parens and the logical operators && and ||.  Some examples:
> 
> # echo "((sig >= 10 && sig < 15) || sig == 17) && comm != bash" > filter
> 
> # echo "common_preempt_count > 4" > filter
> 
> # echo "common_preempt_count > 4 && common_pid != 0" > filter
> 
> It also does some basic error reporting, which you can see by cat'ing
> the filter file after a failed set (this needs a little more work to
> report the error position, but is still useful):
> 
> # echo "(sig >= 10 && sig < 15) || dsig == 17) && comm != bash" > filter
> -bash: echo: write error: Invalid argument
> # cat filter
> (sig >= 10 && sig < 15) || dsig == 17) && comm != bash
> ^
> parse_error: Unbalanced parens
> 
> It should be relatively easy to add new operators; it's implemented as a
> standard infix to postfix converter - when a filter is defined, as
> before, it creates a set of predicates that are evaluated efficiently at
> run-time.
> 
> I tried to make the parser itself reusable so that it could also be
> pointed at a completely separate set of operators and an unevaluated
> operand, with the resulting expression components available in the
> intermediate postfix list. e.g. for say a field of type dev_t, the
> parser could be set up and pointed at an operand of the form (8,3) or
> 8:3 or /dev/sda, and the parsed results retrieved from the parse state
> object, something like this:
> 
> enum kdev_t_filter_op_ids
> {
>        COMMA_OP,
> }; 
> 
> struct filter_op kdev_t_filter_ops[] = {
>        { COMMA_OP, ",", 1 },
>        { NO_OP, "NO_OP", 0 },
>        { OPEN_PAREN_OP, "(", 0 },
> };
> 
> parse_init(parse_state, kdev_t_filter_ops, dev_string);
> filter_parse(parse_state);
> 
> The parsed operator and operands could then be found in the
> parse_state.postfix list and used to generate the dev_t value, or if it
> was specified as a string ('sda' or /dev/sda), there would only be one
> item in the list which could be used in that case to look up the value.
> 

Hi Tom,

Cool stuff. I just skimmed the patches and did not see anything 
I object to.

Acked-by: Steven Rostedt <rostedt@goodmis.org>

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