Re: [RFC][PATCH 4/5] tracing/filters: Provide basic regex support

[Frederic Weisbecker <fweisbec@gmail.com>]

On Thu, Aug 06, 2009 at 09:14:27AM +0800, Li Zefan wrote:
> Frederic Weisbecker wrote:
> > On Mon, Aug 03, 2009 at 01:39:58PM +0800, Li Zefan wrote:
> >> Frederic Weisbecker wrote:
> >>> This patch provides basic support for regular expressions in filters.
> >>> The common filter file doesn't support any regex but a new
> >>> filter_regex file is created for each subsystem/event.
> >>>
> >>> It supports the following types of regexp:
> >>>
> >>> - *match_beginning
> >>> - *match_middle*
> >>> - match_end*
> >>> - !don't match
> >>>
> >> I don't see why adding "filter_regex" is necessary, why not just make
> >> "filter" support regex?
> > 
> > I did that because I feared about people beeing unable to filter using
> > * as a real character inside a filter string.
> > If we are using only one file, we are forced to get the '*' interpreted.
> > That would also break the ABI.
> > 
> 
> I think we don't maintain stable ABI for debugfs and we've been changing
> the "ABI" in debugfs/tracing/, but of course we shouldn't change it
> without good reasons.


Yeah. May be I'm too much careful there but i prefer not to take the risk.

 
> One alternative is to use '"' to prevent '*' to be translated, but seems
> using "filter_regex" is more convenient, so I agree with this patch.


The problem is that most of the time, the '"' is about mandatory to delimit
a string.
Say you want to filter the lock name &REISERFS_SB(sb)->lock, you can't do that
by just typing:

echo name == &REISERFS_SB(sb)->lock > events/lockdep/filter

because the '&' character is considered as an operator and that will trigger
an error.
Instead you must type:

echo 'name == "&REISERFS_SB(sb)->lock"' > events/lockdep/filter

The '' are there to delimit the string for echo, and the "" are interpreted
by the filter api which take it as a whole string and not strings interleaved
with operators. I even fear - and > may be considered as operators if we omit
the "".

I also thought about using an antislash for those who don't want the * to
be interpreted. But although it seems intuitive, it's not as much as two
distinct and visible files.

Also, we can think about the fact the regexp support could be extended one
day if someone needs to. And we could then encounter even more ambiguous
characters such as $, ^, [, {, etc...