[lkml]   [2014]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 00/28] ktap: A lightweight dynamic tracing tool for Linux

* Jovi Zhangwei <> 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

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



 \ /
  Last update: 2014-03-31 10:01    [W:0.264 / U:9.900 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site