Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751631AbWIOPCs (ORCPT ); Fri, 15 Sep 2006 11:02:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751632AbWIOPCs (ORCPT ); Fri, 15 Sep 2006 11:02:48 -0400 Received: from opersys.com ([64.40.108.71]:53255 "EHLO www.opersys.com") by vger.kernel.org with ESMTP id S1751628AbWIOPCs (ORCPT ); Fri, 15 Sep 2006 11:02:48 -0400 Message-ID: <450AC2FA.70203@opersys.com> Date: Fri, 15 Sep 2006 11:12:58 -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: Jes Sorensen CC: Ingo Molnar , Roman Zippel , Mathieu Desnoyers , linux-kernel@vger.kernel.org, Christoph Hellwig , Andrew Morton , Ingo Molnar , Greg Kroah-Hartman , Thomas Gleixner , Tom Zanussi , ltt-dev@shafik.org, Michel Dagenais Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108 References: <20060914033826.GA2194@Krystal> <20060914112718.GA7065@elte.hu> <20060914135548.GA24393@elte.hu> <20060914171320.GB1105@elte.hu> <20060914181557.GA22469@elte.hu> <4509A54C.1050905@opersys.com> <450A9EC9.9080307@opersys.com> <450A9D4B.1030901@sgi.com> <450AB408.8020904@opersys.com> <450AB90C.9000403@sgi.com> In-Reply-To: <450AB90C.9000403@sgi.com> 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: 2152 Lines: 54 Jes Sorensen wrote: > There very few tracepoints in this category, Wow, that's progress. > the only things you can > claim are more or less generic are syscalls, and tracing syscall > handling is tricky. If there are implementation issue, I trust an adequate solution can be found by using the tested-and-proven method of posting stuff on the lkml for review. > This is grossly over simplifying things and why the whole things doesn't > hold water. There is no such thing as 'the place' to put a specific > tracepoint. > > Especially when we start talking about things like tracepoints in the > scheduler. I do not underestimate the difficulty of selecting such tracepoints. This is why I chose not to maintain other people's specific tracepoints. I realize this is a tough problem, but I also trust subsystem maintainers are smart enough to make the appropriate decision. Obviously for such things like the scheduler, any fine-grained instrumentation will draw a barrage of criticism from anyone since a lot of stuff depends on it. Either the lkml process works or it doesn't, but it isn't for me to decide. > Note that I haven't been referring to debug tracepoints at any point in > this debate. You're right, but others have happily intermingled the whole lot, and I just wanted to document my personal categorization on lkml for all to see. > You seem to think that it's fine to add instrumentation in the syscall > path as an example as long as it's compiled out. Well on some > architectures, the syscall path is very sensitive to alignment and there > may be restrictions on how large the stub of code is allowed to be, like > a few hundred bytes. Just because things work one way on x86, doesn't > mean they work like that everywhere. If ltt failed to implement such things appropriately, then we apologize. That fact doesn't preclude proper implementation in the future, however. 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/