lkml.org 
[lkml]   [2013]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Re: ktap inclusion in drivers/staging/?
(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




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