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

    On Mon, Mar 31, 2014 at 3:17 PM, Ingo Molnar <mingo@kernel.org> wrote:
    >
    > * 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?
    >

    From long experiences of ktap development, what make me really
    love ktap is:

    1) Availability
    ktap is only available tool to use in small embedded platform, stap
    and BPF both need GCC now, stap have its own language, so it's much
    better than BPF.
    (IMO there may need several years to complete a skeleton of dynamic
    tracing script language, see stap and dtrace)

    2) Simplicity
    ktap is simplest dynamic scripting trace solution now in Linux world,
    compare with stap/dtrace/BPF.
    a). It have simple syntax which make many people like it, it have
    b). It have simple associate array, make dynamic tracing powerful.
    c). It have a simple compiler which only have 87K in x86_64.
    d). It have a simple tracing syntax which constant with perf events.

    3) Safety
    ktap already delivered its safety to end user, many people use ktap
    in their dev lab to investigate problem.
    But BPF need time to prove its safety, especially proved by end user,
    and IMO BPF safety check would be more complex if the runtime
    support more features as time goes.

    4). Samples
    Many people like those ktap samples, ktap shows the attractive by
    samples.

    Even I so love ktap and would like share ktap values to everyone, but in
    technical point of view, I still agree with you that there should have
    unified scripting engines in kernel if that engine can service for many
    domains(like networking), but that solution should show its availability/
    simplicity/safety firstly to user, not just proved by end user.

    Dynamic tracing scripting environment should contains:
    simple compiler, clean language syntax, fast script engine,
    associative array, aggregation, kstack, ustack, event management,
    ring buffer, samples, tapset/library, CTF, etc.

    ktap already fixed most of these issues by its simple design, but
    BPF only have "script engine" part(its associative array still cannot
    vmalloc), which have long road before could use by end user.

    ktap is not just bring a bytecode engine, it bring a complete simple
    dynamic tracing environment to end user, it bring clean language syntax,
    samples, flexible table, perf like event management, etc, those is the
    key part to end user, not bytecode engine, so if we can develop simple
    BPF compiler with similar ktap syntax in some day, then we can replace
    kp_lex.c/kp_parse.c/kp_vm.c, and there have zero reason why other
    parts cannot be shared(associative array, aggregation, kstack, ustack,
    event management, ring buffer, samples, tapset/library, CTF, etc).

    So ktap is deviling a simple designed tracing script environment,
    but BPF just provide script engine which still not proved by end user
    in many facts(Availability/Simplicity/Safety).

    Sorry for the length of this reply.

    Thanks.

    Jovi


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