Message-ID: <Pine.LNX.4.64.0609171935070.6761@scrub.home>
Date:	Sun, 17 Sep 2006 22:37:19 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Paul Mundt <lethal@...ux-sh.org>,
	Karim Yaghmour <karim@...rsys.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>, Jes Sorensen <jes@....com>,
	Andrew Morton <akpm@...l.org>,
	Tom Zanussi <zanussi@...ibm.com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Christoph Hellwig <hch@...radead.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	William Cohen <wcohen@...hat.com>,
	"Martin J. Bligh" <mbligh@...igh.org>
Subject: Re: tracepoint maintainance models

Hi,

On Sun, 17 Sep 2006, Ingo Molnar wrote:

> Static tracers also need the 
> guarantee of a _full set_ of static markups. It is that _guarantee_ of a 
> full set that i'm arguing against primarily.

To those who are still reading this, let's fill this with a bit of 
meaning (Ingo is unfortunately rather unspecific here):

What is this "_full set_ of static markups" needed/used by tracers?

A tracer can of course export all kinds of information, a lot of this 
would only be interesting to a few users. Nevertheless there is a set of 
information, which is interesting to many users. Let's take a minimal set 
of just the information "schedule task from A to B", this information is 
needed in many traces in order to understand what's going on in the 
kernel.

Let's use this simple set to look at a few of myths around static tracing, 
which Ingo brings up over and over without really proving it.

Scheduling is one of the basic kernel functions, how the actual scheduling 
is done is in a constant flux, but over the years it always ended up in a 
call to switch_to(), so any kernel developer could easily maintain such a 
tracepoint. The exported information is also that simple that it's easy to 
guarantee that this information is available over many kernel version to 
come.

So what we have now is a minimal set of tracepoints, which is equally 
useful to any tracer, which is easy to maintain and reasonably easy to 
guarantee that it exists. Will there be any absolute guarantees, that this 
set will exist forever? Of course not, but it's not needed, should there 
be any change to it, it will very likely announce itself in a development 
tree and userspace tools can adjust to it.

Static tracing of course has its limitations, it's of course not possible 
to export any kind of information with in a standard way via the standard 
kernel, but nobody is asking for this. The kind of information requested 
is very much like the one above, all that has been asked for is _basic_ 
set of tracing information, which can be easily managed and is likely 
available and as I just proved such set does exist, so why should we not 
make it available to everyone?

Will this set satisfy anyone? Of course not, but anyone can easily add his 
own trace points (statically or dynamically).

Will this set be only for the benefit of static tracers? No, this basic 
set of traces is needed by all tools, so it's not ltt-centric at all. It 
will help in the unification of the various trace tools, so that they can 
share as much as possible.

So why again should this information only available to dynamic tracers?

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