Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751307AbWIOUWN (ORCPT ); Fri, 15 Sep 2006 16:22:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751310AbWIOUWN (ORCPT ); Fri, 15 Sep 2006 16:22:13 -0400 Received: from www.osadl.org ([213.239.205.134]:32229 "EHLO mail.tglx.de") by vger.kernel.org with ESMTP id S1751307AbWIOUWM (ORCPT ); Fri, 15 Sep 2006 16:22:12 -0400 Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108 From: Thomas Gleixner Reply-To: tglx@linutronix.de To: karim@opersys.com Cc: Andrew Morton , Paul Mundt , Jes Sorensen , Roman Zippel , Ingo Molnar , Mathieu Desnoyers , linux-kernel@vger.kernel.org, Christoph Hellwig , Ingo Molnar , Greg Kroah-Hartman , Tom Zanussi , ltt-dev@shafik.org, Michel Dagenais In-Reply-To: <450B0585.5070700@opersys.com> References: <20060914181557.GA22469@elte.hu> <4509A54C.1050905@opersys.com> <450A9EC9.9080307@opersys.com> <20060915132052.GA7843@localhost.usen.ad.jp> <20060915135709.GB8723@localhost.usen.ad.jp> <450AB5F9.8040501@opersys.com> <450AB506.30802@sgi.com> <450AB957.2050206@opersys.com> <20060915142836.GA9288@localhost.usen.ad.jp> <450ABE08.2060107@opersys.com> <1158332447.5724.423.camel@localhost.localdomain> <20060915111644.c857b2cf.akpm@osdl.org> <1158348954.5724.481.camel@localhost.localdomain> <450B0585.5070700@opersys.com> Content-Type: text/plain Date: Fri, 15 Sep 2006 22:23:00 +0200 Message-Id: <1158351780.5724.507.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3310 Lines: 67 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/