Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965021AbWIQQ5N (ORCPT ); Sun, 17 Sep 2006 12:57:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965022AbWIQQ5N (ORCPT ); Sun, 17 Sep 2006 12:57:13 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:48355 "EHLO mx2.mail.elte.hu") by vger.kernel.org with ESMTP id S965021AbWIQQ5M (ORCPT ); Sun, 17 Sep 2006 12:57:12 -0400 Date: Sun, 17 Sep 2006 18:45:28 +0200 From: Ingo Molnar To: Roman Zippel Cc: Thomas Gleixner , karim@opersys.com, Andrew Morton , Paul Mundt , Jes Sorensen , 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 Message-ID: <20060917164528.GA2019@elte.hu> References: <20060915231419.GA24731@elte.hu> <20060916082214.GD6317@elte.hu> <20060916230031.GB20180@elte.hu> <20060917084207.GA8738@elte.hu> <20060917152527.GC20225@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-ELTE-SpamScore: -2.9 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.9 required=5.9 tests=ALL_TRUSTED,AWL,BAYES_50 autolearn=no SpamAssassin version=3.0.3 -3.3 ALL_TRUSTED Did not pass through any untrusted hosts 0.5 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] -0.1 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2714 Lines: 55 * Roman Zippel wrote: > > to both points i (and others) already replied in great detail - > > please follow up on them. (I can quote message-IDs if you cannot > > find them.) > > What you basically tell me is (rephrased to make it more clear): > Implement kprobes support or fuck off! [...] What i am saying (again and again) is: "the other option you suggest is not acceptable to me because a better solution exists" [for the many reasons outlined before]. Think about the STREAMS example: there too _that_ particular approach was rejected, because a better solution existed. (although it was a _much_ larger body of code that was rejected) I'm not "forcing" kprobes on you: you can invent whatever other approach that solves the problems i and others raised, or you can have your own separate patchset - this is standard kernel acceptance procedure. Granted, kprobes is an existing solution with extensive existing infrastructure, so it's IMO the easiest solution technically, but you are certainly not 'forced' to do it. You want the feature on your architecture _without_ kprobes, solve the problems. > [...] You make it very clear, that you're unwilling to support static > tracers even to point to make _any_ static trace support impossible. > It's impossible to discuss this with you, because you're absolutely > unwilling to make any concessions. [...] Because we either accept the concept of static tracing or not - unfortunately there's no meaningful middle ground. I'd love it if there was some meaningful middle-ground, because then we'd not have this lengthy discussion at all. But sometimes such situations do happen. Same was true for STREAMS: the only choice was to either it was accepted or it was rejected. One cannot get a "little bit pregnant". The "add some static markups" suggestion is IMO just tactical pretense: static tracing will only be fully functional once it grows a comprehensive set of static tracepoints, so once we accept a "little bit" of static tracing where all the tools are built around a full set of tracepoints, we've created an expectance to have all of it. Hence my suggestion: forget static tracing for the LTT engine and concentrate on dynamic tracepoints with _static markups_. Do you realize that dynamic tracers can insert _function calls_ into static markups, today? [and i'm not talking about djprobes here but current existing SystemTap behavior.] Ingo - 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/