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

    * Roman Zippel <> wrote:

    > > On the other side there is the main kernel, which, if it ever
    > > accepted static tracepoints, could probably never get rid of them.
    > If they are useful and not hurting anyone, why should we?

    FYI, whether it is true that "they not hurting anyone" is one of those
    "secondary issues" that I analyzed in great detail in the emails
    yesterday, and which you opted not to "further dvelve into":

    Message-ID: <>:

    ' That is a constant kernel maintainance drag that i feel
    uncomfortable about. '

    Message-ID: <>:

    'That's far from "virtually no maintainance overhead".'

    Message-ID: <>:

    'static tracepoints are a maintainance problem: once added _they can
    not be removed without breaking static tracers_.'

    I still very much opine that your claim that static tracepoints are not
    hurting anyone is false: they can cause significant maintainance
    overhead in the long run that we cannot remove, and these costs
    integrate over a long period of time.

    We have statements from two people who have /used and hacked/ LTT in
    products and have seen LTT's use, indicating that the maintainance
    overhead is nonzero and that the combined number of tracepoints in use
    by actual customers is much larger than posited in this thread. We also
    have LTT proponents disputing that and suggesting that the long-term
    maintainance overhead is very low. So even taking my opinion out of the
    picture, the picture is far from clear. If we put my opinion back into
    the picture: i base it on my first-hand experience with tracers. [**]

    so at least to me the rule in such a situation is clear: if we have the
    choice between two approaches that are useful in similar ways [*] but
    one has a larger flexibility to decrease the total maintainance cost,
    then we _must_ pick that one.

    This really isnt rocket science, we do such decisions every day. We did
    that decision for STREAMS too. (which STREAMS argument you ignored for a
    number of times.) STREAMS was a similar situation: people wanted "just a
    few unintrusive hooks which you could compile out" for external STREAMS
    functionality to hook into.

    and unlike STREAMS, in the LTT case it's not the totality of the project
    that is being disputed: i only dispute the static tracing aspect of it,
    which is a comparatively small (but intrusive) portion of a project that
    consists of a 26,000 lines kernel patchset and a large body of userspace


    [*] furthermore, dynamic tracing is not only "similarly useful", it is
    _more useful_ because it allows alot more than static tracing does.
    That's why i analyzed the "secondary issue" of the usefulness of
    dynamic tracers: the decision gets easier if one of the technologies
    is fundamentally more capable.

    [**] Also, just yesterday i tried to merge the 2.6.17 version of the LTT
    patchset to 2.6.18, and it created non-trivial rejects left and
    right. That is a further objective indicator to me - if something
    has low maintainance cost, how come its patchset is so intrusive
    that it cannot survive 3 months of kernel development flux? If it's
    intrusive, shouldnt we have the fundamental option to shift that
    maintainance overhead out of the core kernel, back to the people
    that want those features?
    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-17 10:53    [W:0.025 / U:4.472 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site