lkml.org 
[lkml]   [2006]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

    Jes Sorensen wrote:
    > Karim> And that's actually a problem for those who maintain such
    > Karim> dynamic trace points.
    >
    > And who should pay here? The people who want the tracepoints or the
    > people who are not interested in them?

    If you'd care to read through the thread you'd notice I've demonstrated
    time and again that those static trace points we're mostly interested
    in a never-changing. Lest something fundamentally changes with the
    kernel, there will always be a scheduling change; etc. This
    "instrumentation is evil" mantra is only substantiated if you view
    it from the point of view of someone who's only used it to debug code.
    Yet, and I repeat this again, instrumentation for in-source debugging
    is but a corner case of instrumentation in general.

    > You have obviously never tried to maintain a codebase for a long
    > time.

    Please, this is not constructive. I've never really grasped the need
    for posturing on LKML. Jes, I'm not going to fight a war of resumes
    with you. If you think I'm incompetent then there's very little I can
    do to change your mind.

    > Not to mention that some of the classical places people wish to add
    > those static tracepoints are in performance sensitive codepaths,
    > syscalls for example.

    And this argument ignores everything I said on how there does not need
    be the limitation currently known to previous static tracing mechanisms.

    > You can do pretty much everything you want to do with dynamic
    > tracepoints, it's just a matter of whether you want to dump the burden
    > of maintenance on someone else. Been there done that, had to show
    > people in the past how to do with dynamic points what they insisted
    > had to be done with static points.

    Yes, Mr. Scrub, I mean kprobes is your answer. The only reason you can
    get away with this argument is if you view it exclusively from the
    point of view of kernel development. And that's why you're wrong.

    > So you maintain the tracepoints in the kernel and you are offering to
    > take over maintenance of all code that now contain these tracepoints?

    Please explain, honestly, why the following instrumentation point is
    going to be a maintenance drag on the person modifying the scheduler:
    @@ -1709,6 +1712,7 @@ switch_tasks:
    ++*switch_count;

    prepare_arch_switch(rq, next);
    + TRACE_SCHEDCHANGE(prev, next);
    prev = context_switch(rq, prev, next);
    barrier();

    And please, don't bother complaining about the semantics, they can
    be changed. I'm just arguing about location/meaning/content.

    > You add your static tracepoints, next week someone else wants some
    > very similar but slightly different points, the following week it's
    > someone else. Thanks, but no thanks.

    Obviously there's no point in me spelling any code of conduct to
    anyone, Martin has already pointed out that it's up to the subsystem
    maintainers to decide what's appropriate and what's not, as is
    customary anyway. But the issue I'm putting forth here is that there
    is value for allowing outsiders to understand the dynamic behavior of
    your code and the only person who can do that best is the person
    writing the code. It is then that person's responsibility to
    distinguish between instrumentation they may find important to debug
    their code and instrumentation that would be relevant to those using
    their code. And if you've maintained code long enough, and I trust
    you do, you would see that there is a clear difference between both.

    Thanks,

    Karim
    --
    President / Opersys Inc.
    Embedded Linux Training and Expertise
    www.opersys.com / 1.866.677.4546
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-09-15 14:21    [W:4.198 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site