Message-Id: <1158351780.5724.507.camel@localhost.localdomain>
Date:	Fri, 15 Sep 2006 22:23:00 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	karim@...rsys.com
Cc:	Andrew Morton <akpm@...l.org>, Paul Mundt <lethal@...ux-sh.org>,
	Jes Sorensen <jes@....com>,
	Roman Zippel <zippel@...ux-m68k.org>,
	Ingo Molnar <mingo@...e.hu>,
	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, 2006-09-15 at 15:56 -0400, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
> > One thing which is much more important IMHO is the availablity of
> > _USEFUL_ postprocessing tools to give users a real value of
> > instrumentation. This is a much more complex task than this whole kernel
> > instrumentation business. This also includes the ability to coordinate
> > user space _and_ kernel space instrumentation, which is necessary to
> > analyse complex kernel / application code interactions. 
> 
> And of course the usefulness of such postprocessing tools is gated
> by the ability of users to use them on _any_ kernel they get their
> hands on. Up to this point, this has not been for *any* of the
> existing toolsets, simply because they require the user to either
> recompile his kernel or modify his probe points to match his kernel.

So this has to be changed. And requiring to recompile the kernel is the
wrong answer. Having some nifty tool, which allows you to define the set
of dynamic trace points or use a predefined one is the way to go.

> Until users can actually do without either of these steps (which is
> only possible with static markup) 

Generalization like that are simply wrong. Static markup is not a
panacea. It might help for some things in the first place, but it is not
flexible enough in the long run. It is an engineering challenge to make
the "static" trace rules autogenerated by some means as Andrew pointed
out several times in this thread (see patch(1)), so we can provide a
useful ad hoc set for the users.

> We don't need separate popstprocessing tool teams. The only reasons
> 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! LTT did not manage to solve the problem in a generic,
mainline acceptable way. If you really believe that Kprobes / Systemtap
is just a $corporate maliciousness to kick you out of business, then I
really start to doubt your sanity.

This has nothing to do with postprocessing and tracepoint creation
tools. The postprocessing stuff is not in the scope of mainlining. Once
a halfways future proof interface is available, tools will come up
within no time. There are a lot of companies out there who have the
interest and the capabilites to do an intergration into Eclipse to name
one example. They will not start to spend a second of work time until
there is a consolidated instrumentation core in the kernel.

> When I started involving myself in Linux development a decade ago,
> I honestly did not think I'd ever see this kind of stuff happen,
> but, hey, that's life.

- ENOPARSE

	tglx


-
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