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]
Date:	Fri, 15 Sep 2006 13:13:17 -0700
From:	Andrew Morton <akpm@...l.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	tglx@...utronix.de, karim@...rsys.com,
	Paul Mundt <lethal@...ux-sh.org>, Jes Sorensen <jes@....com>,
	Roman Zippel <zippel@...ux-m68k.org>,
	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

On Fri, 15 Sep 2006 20:19:07 +0200
Ingo Molnar <mingo@...e.hu> wrote:

> 
> * Andrew Morton <akpm@...l.org> 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.

systemtap and ltt are the only full-scale tracing tools which target
sysadmins and applciation developers of which I am aware..

> > 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?

My point is that I respect Karim and Frank's experience.  I in fact
disagree with them (or at least, I want to).  But they've been there, and I
haven't.  So I listen.

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

In the bit of text which you snipped I was agreeing with this...

Look, if Karim and Frank (who I assume is a systemtap developer) think that
we need static tracepoints then I have no reason to disagree with them. 
What I would propose is that:

a) Those tracepoints be integrated one at a time on well-understood
   grounds of necessity.  Tracepoints _should_ be added dynamically.  But
   if there are instances where that's not working and cannot be made to
   work then OK, in we go.

b) Saying "we need the static tracepoints because the line numbers keep
   on changing" is not, repeat not a justification for static tracepoints. 
   It's a SMOP to develop tracepoint-adding code which can handle line
   numbers changing.  lwall did it.

c) Any static tracepoints should be seen as corner-case augmentation of
   existing dynamic tracing framework(s).  IOW: I see no justification at
   this time for adding complete new second set of backend
   accumulation/reporting/management infrastructure (ie: LTT core).


Shorter version: I agree with Frank.
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ