Message-ID: <Pine.LNX.4.64.0609152314250.6761@scrub.home>
Date:	Fri, 15 Sep 2006 23:27:58 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Thomas Gleixner <tglx@...utronix.de>, karim@...rsys.com,
	Andrew Morton <akpm@...l.org>,
	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

Hi,

On Fri, 15 Sep 2006, Ingo Molnar wrote:

> > Nobody is taking dynamic tracing away!
> > You make it sound that tracing is only possible via dynamic traces.
> > If I want to use static tracepoints, why shouldn't I?
> 
> because:
> 
>  - static tracepoints, once added, are very hard to remove - up until
>    eternity. (On the other hand, markers for dynamic tracers are easily 
>    removed, either via making the dynamic tracer smarter, or by 
>    detaching the marker via the patch(1) method. In any case, if a 
>    marker goes away then hell does not break loose in dynamic tracing 
>    land - but it does in static tracing land.

This is simply not true, at the source level you can remove a static 
tracepoint as easily as a dynamic tracepoint, the effect of the missing 
trace information is the same either way.

>  - the markers needed for dynamic tracing are different from the LTT
>    static tracepoints.

What makes the requirements so different? I would actually think it 
depends on the user independent of the tracing is done.

>  - a marker for dynamic tracing has lower performance impact than a 
>    static tracepoint, on systems that are not being traced. (but which 
>    have the tracing infrastructure enabled otherwise)

Anyone using static tracing intents to use, which makes this point moot.

>  - having static tracepoints dillutes the incentive for architectures to
>    implement proper kprobes support.

Considering the level of work needed to support efficient dynamic tracing 
it only withholds archs from tracing support for no good reason.

> > > > there are separate project teams is because managers in key 
> > > > positions made the decision that they'd rather break from existing 
> > > > projects which had had little success mainlining and instead use 
> > > > their corporate bodyweight to pressure/seduce kernel developers 
> > > > working for them into pushing their new great which-aboslutely- 
> > > > has-nothing-to-do-with-this-ltt-crap-(no,no, we actually agree 
> > > > with you kernel developers that this is crap, this is why we're 
> > > > developing this new amazing thing). That's the truth plain and 
> > > > simple.
> > >
> > > Stop whining!
> > 
> > So we're back to personal attacks now. :-(
> 
> hm, so you dont consider the above paragraph a whine. How would you 
> characterize it then? A measured, balanced, on-topic technical comment? 
> I'm truly curious.

It's sarcastic, but considering the disrespect towards Karim, I don't 
blame him. At some point the "whining" argument was funny, but lately it's 
only used to descredit people.

bye, Roman
-
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