* Roman Zippel <[email protected]> wrote:
> Hi,
>
> On Fri, 15 Sep 2006, Ingo Molnar wrote:
>
> > > What Karim is sharing with us here (yet again) is the real in-field
> > > experience of real users (ie: not kernel developers).
> >
> > well, Jes has that experience and Thomas too.
> >
> > > I mean, on one hand we have people explaining what they think a
> > > tracing facility should and shouldn't do, and on the other hand we
> > > have a guy who has been maintaining and shipping exactly that thing to
> > > (paying!) customers for many years.
> >
> > so does Thomas and Jes. So what's the point?
>
> That only Karim's experience is being in question here?
i think you misunderstood, please read the paragraphs above. They
suggest that there's "real in-field experience of real users" against
"people explaining what they think a tracing facility should and
shouldn't do". I only pointed out that those people (Thomas, Jes) dont
just randomly express their opinion but have actual in-field experience
too (of paying customers), about the very topic at hand.
> > i judge LTT by its current code quality, not by its proponents shouting
> > volume - and that quality is still quite poor at the moment. (and then
> > there are the conceptual problems too, outlined numerous times) I have
> > quoted specific example(s) for that in this thread. Furthermore, LTT
> > does this:
> >
> > 246 files changed, 26207 insertions(+), 71 deletions(-)
> >
> > and this gives me the shivers, for all the reasons i outlined.
>
> Well, I'm first to admit that LTT needs improvement, but that has
> never been the point.
that might not be your point, but that very much is my point. I do claim
that LTT's problems arise out of its fundamental mistake on the kernel
side: that it is a static tracer that tries to be too many things to too
many people. SystemTap is available here and today on an unmodified
upstream kernel. LTT has been in this shape for the past ~8 years. But
if you wish you can certainly prove me wrong via for example cleaning up
and shrinking LTT down to a size and impact that is not scary anymore,
with the same functionality, and the clear future path for the removal
of its dependencies. I tried to argue that in the abstract, but please
by all means feel free to prove me wrong. (or argue against my specific
points)
> We need to get to some kind of agreement what level of tracing Linux
> should support in general, preferably something that is easy to
> integrate and usable by everyone. Especially the latter means that
> there is not one true solution, [...]
sorry, but i disagree. There _is_ a solution that is superior in every
aspect: kprobes + SystemTap. (or any other equivalent dynamic tracer)
> At this point you've been rather uncompromising [...]
yes, i'm rather uncompromising when i sense attempts to push inferior
concepts into the core kernel _when_ a better concept exists here and
today. Especially if the concept being pushed adds more than 350
tracepoints that expose something to user-space that amounts to a
complex external API, which tracepoints we have little chance of ever
getting rid of under a static tracing concept.
i'm also looking at it this way too: you already seem to be quite
reluctant to add kprobes to your architecture today. How reluctant would
you be tomorrow if you had static tracepoints, which would remove a fair
chunk of incentive to implement kprobes?
Ingo
-
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]
