* Roman Zippel <[email protected]> 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: <[email protected]>:
' That is a constant kernel maintainance drag that i feel
uncomfortable about. '
Message-ID: <[email protected]>:
'That's far from "virtually no maintainance overhead".'
Message-ID: <[email protected]>:
'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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
