Messages in this thread | | | Date | Sat, 3 Oct 2009 13:49:51 +0200 | From | Frederic Weisbecker <> | Subject | Re: [GIT PULL v2] bkl tracepoints + filter regex support |
| |
On Sat, Sep 26, 2009 at 11:47:06AM -0400, Frank Ch. Eigler wrote: > > Hi - > > > Frederic Weisbecker <fweisbec@gmail.com> writes: > > >> > 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 :-/ > > Are y'all convinced that a little ascii language parser/interpreter is > the right thing to put into the kernel, as opposed to bytecode (with a > userspace compiler)? > > - FChE
We need something directly understandable from the kernel interfaces. As an example we don't want the ftrace users to bother about compiling a string before applying it on an event filter through ftrace debugfs interface, we want it directly usable without middle-state in the worklow.
That's also the same for perf syscalls users.
Moreover it's a really small language, based on predicates. Fetching strings against bytecodes won't make that much differences in the amount of kernel code to maintain.
| |