Messages in this thread | | | Date | Sat, 26 Oct 2013 10:59:55 +0200 | From | Ingo Molnar <> | Subject | Re: ktap inclusion in drivers/staging/? |
| |
* 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.
(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.
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.
Thanks,
Ingo
| |