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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060915200559.GB30459@elte.hu>
Date:	Fri, 15 Sep 2006 22:05:59 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	Andrew Morton <akpm@...l.org>, tglx@...utronix.de,
	karim@...rsys.com, Paul Mundt <lethal@...ux-sh.org>,
	Jes Sorensen <jes@....com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
	Michel Dagenais <michel.dagenais@...ymtl.ca>
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

* Roman Zippel <zippel@...ux-m68k.org> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/