* Jovi Zhangwei <jovi.zhang...@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
--
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/
