Message-ID: <526E55B9.20902@hitachi.com>
Date:	Mon, 28 Oct 2013 21:16:57 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Jovi Zhangwei <jovi.zhangwei@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
	Frédéric Weisbecker 
	<fweisbec@...il.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Tom Zanussi <tom.zanussi@...ux.intel.com>,
	Namhyung Kim <namhyung@...nel.org>,
	David Ahern <dsahern@...il.com>, Jiri Olsa <jolsa@...hat.com>,
	"yrl.pp-manager.tt@...achi.com" <yrl.pp-manager.tt@...achi.com>
Subject: Re: Re: ktap inclusion in drivers/staging/?

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


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