lkml.org 
[lkml]   [2014]   [Apr]   [8]   [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
    On Fri, Apr 4, 2014 at 3:36 PM, Ingo Molnar <mingo@kernel.org> wrote:
    >
    > * Jovi Zhangwei <jovi.zhangwei@gmail.com> wrote:
    >
    >> I don't see any suggestion about integrating BPF before this review
    >> cycle.
    >
    > Hm, I mentioned it at the kernel summit to folks who raised the ktap
    > subject, but apparently not over email. I assumed a new ktap
    > submission would come quickly.
    >
    > Anyway, considering how BPF is integrating with (and hopefully
    > replacing) tracing filters, it makes sense to apply the same concept
    > in the ktap case as well.
    >
    It seems that kernel developers want a C based tracing filter, BPF
    rooted from C(Compiler, performance, and networking target),
    but ktap designed from a different point of view, which highlights
    simplicity and flexibility, this simplicity and flexibility is not only
    presented by simple syntax, but also in its bytecode engine.

    trace syscalls:* {
    print(cpu, pid, execname, argstr, stack())
    }

    Each expression have own type in kernel, the type is not judged by
    userspace compiler, this make print expression much much easy,
    also make handle associate array(and aggregation) extremely simple.
    If we force replace ktap core with a much "static" bytecode engine,
    then it will lose the highlight feature: simplicity and flexibility.

    ktap is not designed to be a built-in tracing filter and not purpose for
    high performance bytecode engine(can use for networking), BPF is
    suit for that way, but that is not a design flaw in ktap, it's designed
    to be like that.

    Obviously many people love ktap nowadays even though it's not a
    C-family language, people can use ktap one-liner to do interesting
    things(http://brendangregg.com/ktap.html), and used in real world.
    Also especially people in embedded world like ktap very much,
    they already included ktap into OpenEmebedded as I know.

    It seems that more and more tracing related kernel modules will
    come in future(like https://github.com/draios/sysdig/issues/81),
    so maybe these third-part kernel modules based on tracing export
    symbols should locate in drivers/, not kernel/trace/, today we have
    well defined tracing kernel interface(tracepoint, kprobe, uprobe, perf
    callback),
    no reason to put all these external modules sit in kernel/trace one place,
    especially if the module have real end users in world.

    Thanks.

    Jovi


    \
     
     \ /
      Last update: 2014-04-08 09:41    [W:4.509 / U:0.180 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site