Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

[Ingo Molnar]

* Roman Zippel <zippel@xxxxxxxxxxxxxx> 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: <20060916082347.GG6317@xxxxxxx>:

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

   Message-ID: <20060916082107.GB6317@xxxxxxx>:

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

   Message-ID: <20060916082054.GA6317@xxxxxxx>:

    '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 
tools.

	Ingo

[*] 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/