[lkml]   [2013]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Re: ktap inclusion in drivers/staging/?
(2013/10/26 17:59), Ingo Molnar wrote:
> * Jovi Zhangwei <> wrote:
>> Thanks. An addition question I want to discuss in here is the ktap
>> code structure layout in first patch series, this don't need to
>> dig out any ktap design detail, so we can make agreement on this
>> point, and ease for me to prepare patch series.
>> Do I need to prepare patchset target on staging tree or "real"
>> part of kernel? [...]
> I'd suggest adding it to the core, i.e. kernel/tracing/ and
> kernel/trace/trace_events_filter.c in particular which includes the
> current filter script interpreter.

It means we'll need to put Lua compiler in the kernel...
I just recommend to put the ktap *on* the ftrace or perf. Not directly
integrate it. Bytecode interpreter is good, limited fomula parser is also
good, but IMHO, integrating complete lua compiler into the kernel looks
I think it is just enough to include lua compiler as a tool in the kernel.

> (Please also make sure that the Lua copyright notices get carried
> over properly.)
>> [...] If target on driver/staging/ktap, then kernel code and
>> userspace code still need to locate at same directory, that many
>> people may don't like it.
>> Target on "real" part kernel? - include/trace/ktap (header file
>> common used by interpreter and userspace compiler) -
>> kernel/trace/ktap (interpreter code, ktapvm, pure kernel module) -
>> tools/perf/ktap?(userspace compiler code)
>> As I also agree integrating ktap and perf together, two
>> subsystem can share many codes, so it's better putting ktap
>> userspace into perf directory.
> Once there's a more split-out submission it will be easier to see
> what belongs where. I agree with Pekka that for the user the UI
> should be integrated and obvious.

But, what about perf script ? :)
ktap is for online scripting and perf-script is for offline scripting,
so both are worth to have, I think.

> I'd also like there to be a natural 'extract the script'
> functionality from an installed tap script. This gives more
> flexibiliy and improves security as well: no hidden, binary-only
> crap, every script installed on a running system should be
> extractable in source form, should be reviewable and modifiable.

Would you mean the bytecode should be decodable? or loaded with
source code in the kernel?

Thank you,

IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory

 \ /
  Last update: 2013-10-28 14:21    [W:0.128 / U:1.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site