Date:	Fri, 25 Sep 2009 12:38:07 +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 Fri, Sep 25, 2009 at 11:40:00AM +0200, Peter Zijlstra wrote:
> On Fri, 2009-09-25 at 11:12 +0200, Frederic Weisbecker wrote:
> > That said, the future plans have evolved, and I'm fine if you have
> > changed your opinion and think about a better way to develop this.
> 
> No, but the thing is, IF we're going to freeze this into ABI, then
> there's no second chances.



Right. Once it becomes an ioctl, it becomes an ABI :-/


 
> Using globs in string matches most certainly is useful, no question
> about that.
> 
> But I had understood from previous communications we were going to have
> a C syntax, and there == is a straight comparison.
> 
> If however people have changed their minds (fine with me) and we're now
> going to script like things..



Well, indeed we talked about C syntax, but I didn't think the idea
was that fixed in the rock, hence why I was suprised.


> Anyway, a glob in == just means we have to use another operator if we
> ever want to support actual regexes, ~ would then be recommened I think,
> since that's what awk and I think perl do.


Yeah. For example one may know python but not perl or awk,
other people may be in the opposite situation. But most
developers know the C (at least its basic syntax).

So I'm not sure using such ~ operator is a good idea. I think you're
right in the fact we should stay tight to the C syntax.


> Personally I wouldn't mind things like:
> 
>  glob_match(string, pattern)
>  regex_match(string, pattern)



Yeah, actually that sounds more flexible and more something that people
are familar with, once we consider the future evolutions.



> But everybody involved in this filter stuff needs to agree what
> direction you want to take the language in.



Right!

 

> > I just don't want that this bridge turns out any ftrace uses through debugfs
> > into an overkill.
> > Instead I'd prefer to satisfy both, hence the above proposition.
> 
> So you're proposing to split the filter language? I'm sure that's going
> to confuse a few people ;-)



Hmm, just at this level. That could even be a trace option.
Anyway, it would nice to have other tracing developers
opinion.


 
> Thing is, if you (or others) have a need to experiment with the
> language, then I'm not sure its the right moment to freeze bits into an
> ABI.
> 
> I'm really fine with thing, as long as everybody on the filter side
> knows experimenting isn't really an option and agrees on the direction
> they want to take the language.


Well, I talked about experimenting the language before pushing it as
an ABI because I was afraid we were going too fast.

But I guess the ABI is a requirement to use it through perf ioctl,
and delay that would keep it as a hostage, may be even slow its
development.


> Is there no existing language with a proper license and clean code-base
> we can 'borrow'? That would avoid creating yet another funny language,
> and learning how to implement things all over again.
> 
> Personally I don't think the kernel is the place to experiment in script
> language design, but that's me ;-)


Python? :-)

More seriously, as I said above, I think most developers are familiar with C
syntax, so IMHO this is one of our best possibility.

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

Powered by blists - more mailing lists