Messages in this thread | | | Date | Mon, 31 Mar 2014 09:17:49 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC PATCH 00/28] ktap: A lightweight dynamic tracing tool for Linux |
| |
* Jovi Zhangwei <jovi.zhangwei@gmail.com> wrote:
> Hi All, > > The following set of patches add ktap tracing tool. > > ktap is a new script-based dynamic tracing tool for Linux. > It uses a scripting language and lets the user trace system dynamically. > > Highlights features: > * a simple but powerful scripting language > * register-based interpreter (heavily optimized) in Linux kernel > * small and lightweight > * not depend on the GCC toolchain for each script run > * easy to use in embedded environments without debugging info > * support for tracepoint, kprobe, uprobe, function trace, timer, and more > * supported in x86, ARM, PowerPC, MIPS > * safety in sandbox
I've asked this fundamental design question before but got no full answer: how does ktap compare to the ongoing effort of improving the BPF scripting engine?
There's several efforts here that I'm aware of:
1) 64-bit BPF, integration with ftrace scripting, see this lkml thread:
[RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters
2) better BPF integration with networking:
[PATCH net-next v3 8/9] net: filter: rework/optimize internal BPF interpreter's instruction set
Your patches introduce a separate bytecode interpreter in kernel/trace/ktap/ and that's overlapping with BPF.
From a long term instrumentation code maintenance point of view the last thing we want is several overlapping scripting engines.
Thanks,
Ingo
| |