(2013/10/26 17:59), Ingo Molnar wrote: > > * Jovi Zhangwei <jovi.zhang...@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...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
