linux-kernel - Re: [GIT PULL v2] bkl tracepoints + filter regex support

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]

Date:	Thu, 24 Sep 2009 23:36:33 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Tom Zanussi <tzanussi@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Li Zefan <lizf@...fujitsu.com>
Subject: Re: [GIT PULL v2] bkl tracepoints + filter regex support

On Thu, Sep 24, 2009 at 10:51:29PM +0200, Peter Zijlstra wrote:
> On Thu, 2009-09-24 at 22:44 +0200, Frederic Weisbecker wrote:
> 
> > I don't quite understand why.
> > 
> > Typing file == "*reiserfs*" looks more intuitive.
> > 
> > It's true that the filters should stay tight to the C syntax,
> > but following this guideline up to the point that we are forced to
> > use function expressions to do something that can be expressed
> > much more easily and more intuitively (IMHO), that all sounds like
> > an overkill.
> > 
> > The use of glob is a very primary need for filters, it's
> > so much a basic requirement for it that it should be native
> > in its language.
> 
> The thing that my fingers know is awk syntax:
> 
>  file ~ /reiserfs/
> 
> I'd very much prefer to keep == for strict equality, however the above
> requires actual regex bits.


The strict equality issue was the reason that made me first
split the filter file into "filter" and "filter_regex", that
actually should have been "filter_glob" :-)

But the general opinion was in favour of a single file
supporting these globs, especially since it's a non-abi thing.

In the current state, in its current scope and use, I think these
native globs are the right choice.

But if we start to consider it in a larger scope, used by perf and
may be for even wider uses than trace events, then yes we should
double-check the impact of this syntax change.
 

> Remember, there are no second chances for the filter syntax anymore.


But well, it's not yet an ABI. It's still a baby, although powerful
for filtering, it's not yet a whole scripting language.

Before thinking about it as an ABI, we should develop it, extend
it, use these extensions, spot the weaknesses in the syntax, fix them,
etc...

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