Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932143AbWIOTqz (ORCPT ); Fri, 15 Sep 2006 15:46:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751603AbWIOTqz (ORCPT ); Fri, 15 Sep 2006 15:46:55 -0400 Received: from opersys.com ([64.40.108.71]:48650 "EHLO www.opersys.com") by vger.kernel.org with ESMTP id S1751590AbWIOTqy (ORCPT ); Fri, 15 Sep 2006 15:46:54 -0400 Message-ID: <450B0585.5070700@opersys.com> Date: Fri, 15 Sep 2006 15:56:53 -0400 From: Karim Yaghmour Reply-To: karim@opersys.com Organization: Opersys inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.6) Gecko/20060804 Fedora/1.0.4-0.5.1.fc5 SeaMonkey/1.0.4 MIME-Version: 1.0 To: tglx@linutronix.de 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 Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108 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> In-Reply-To: <1158348954.5724.481.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1974 Lines: 41 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. Until users can actually do without either of these steps (which is only possible with static markup) then the development teams of the various projects will continue having to invest resources chasing the kernel. 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. 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. Karim - 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/