Re: Re: ktap inclusion in drivers/staging/?

[Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>]

(2013/10/26 17:59), Ingo Molnar wrote:
> 
> * Jovi Zhangwei <jovi.zhangwei@gmail.com> 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
crazy.
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,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com