[lkml]   [2006]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Linux Kernel Markers

    * Mathieu Desnoyers <> wrote:

    > +choice
    > + prompt "MARK code marker behavior"

    > +config MARK_KPROBE
    > +config MARK_JPROBE
    > +config MARK_FPROBE
    > + Change markers for a function call.
    > +config MARK_PRINT

    as indicated before in great detail, NACK on this profileration of
    marker options, especially the function call one. I'd like to see _one_
    marker mechanism that distros could enable, preferably with zero (or at
    most one NOP) in-code overhead. (You can of course patch whatever
    extension ontop of it, in out-of-tree code, to gain further performance
    advantage by generating direct system-calls.)

    There might be a hodgepodge of methods and tools in userspace to do
    debugging, but in the kernel we should get our act together and only
    take _one_ (or none at all), and then spend all our efforts on improving
    that primary method of debug instrumentation. As kprobes/SystemTap has
    proven, it is possible to have zero-overhead inactive probes.

    Furthermore, for such a patch to make sense in the upstream kernel,
    downstream tracing code has to make actual use of that NOP-marker. I.e.
    a necessary (but not sufficient) requirement for upstream inclusion (in
    my view) would be for this mechanism to be used by LTT and LKST. (again,
    you can patch LTT for your own purposes in your own patchset if you
    think the performance overhead of probes is too much)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-09-19 10:23    [W:0.022 / U:155.512 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site