Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965210AbWIRBWa (ORCPT ); Sun, 17 Sep 2006 21:22:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965211AbWIRBWa (ORCPT ); Sun, 17 Sep 2006 21:22:30 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:48797 "EHLO mx2.mail.elte.hu") by vger.kernel.org with ESMTP id S965210AbWIRBW3 (ORCPT ); Sun, 17 Sep 2006 21:22:29 -0400 Date: Mon, 18 Sep 2006 03:13:52 +0200 From: Ingo Molnar To: Karim Yaghmour Cc: Mathieu Desnoyers , Paul Mundt , linux-kernel , Ingo Molnar , Jes Sorensen , Andrew Morton , Roman Zippel , Tom Zanussi , Richard J Moore , "Frank Ch. Eigler" , Michel Dagenais , Christoph Hellwig , Greg Kroah-Hartman , Thomas Gleixner , William Cohen , "Martin J. Bligh" Subject: Re: tracepoint maintainance models Message-ID: <20060918011352.GB30835@elte.hu> References: <450D182B.9060300@opersys.com> <20060917112128.GA3170@localhost.usen.ad.jp> <20060917143623.GB15534@elte.hu> <20060917153633.GA29987@Krystal> <20060918000703.GA22752@elte.hu> <450DF28E.3050101@opersys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450DF28E.3050101@opersys.com> 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: 2184 Lines: 55 * Karim Yaghmour wrote: > Ingo Molnar wrote: > > yeah. If you look at the API suggestions i made, they are such. There > > can be differences though to 'static tracepoints used by static > > tracers': for example there's no need to 'mark' a static variable, > > because dynamic tracers have access to it - while a static tracer would > > have to pass it into its trace-event function call. > > That has been your own personal experience of such things. Fortunately > by now you've provided to casual readers ample proof that such > experience is but limited and therefore misleading. The fact of the > matter is that *mechanisms* do not "magically" know what detail is > necessary for a given event or how to interpret it: only *markup* does > that. Karim, i dont usually reply if you insult me (and you've grown a habit of that lately ), but this one is almost parodic. To understand my point, please consider this simple example of a static in-source markup, to be used by a dynamic tracer: static int x; void func(int a) { ... MARK(event, a); ... } if a dynamic tracer installs a probe into that MARK() spot, it will have access to 'a', but it can also have access to 'x'. While a static in-source markup for _static tracers_, if it also wanted to have the 'x' information, would also have to add 'x' as a parameter: MARK(event, a, x); thus for example value of the variable 'x' would be passed to the function that does the static tracing. For dynamic tracers no such 'parameter preparation' instructions would need to be generated by gcc. (thus for example the runtime overhead would be lower for inactive tracepoints) hence, in this specific example, there is a real difference between the markup needed for dynamic tracers, compared to the markup needed for static tracers - to achieve the same end-result of passing (event,a,x) to the tracer. 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/