Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751368AbWISIUK (ORCPT ); Tue, 19 Sep 2006 04:20:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751379AbWISIUK (ORCPT ); Tue, 19 Sep 2006 04:20:10 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:37272 "EHLO mx2.mail.elte.hu") by vger.kernel.org with ESMTP id S1751385AbWISIUI (ORCPT ); Tue, 19 Sep 2006 04:20:08 -0400 Date: Tue, 19 Sep 2006 10:11:24 +0200 From: Ingo Molnar To: Mathieu Desnoyers Cc: "Frank Ch. Eigler" , Paul Mundt , linux-kernel , Jes Sorensen , Andrew Morton , Tom Zanussi , Richard J Moore , Michel Dagenais , Christoph Hellwig , Greg Kroah-Hartman , Thomas Gleixner , William Cohen , "Martin J. Bligh" , ltt-dev@shafik.org, systemtap@sources.redhat.com, Alan Cox Subject: Re: [PATCH] Linux Kernel Markers Message-ID: <20060919081124.GA30394@elte.hu> References: <20060918234502.GA197@Krystal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060918234502.GA197@Krystal> 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: 1650 Lines: 38 * Mathieu Desnoyers wrote: > +choice > + prompt "MARK code marker behavior" > +config MARK_KPROBE > +config MARK_JPROBE > +config MARK_FPROBE > + Change markers for a function call. > +config MARK_PRINT as indicated before in great detail, NACK on this profileration of marker options, especially the function call one. I'd like to see _one_ marker mechanism that distros could enable, preferably with zero (or at most one NOP) in-code overhead. (You can of course patch whatever extension ontop of it, in out-of-tree code, to gain further performance advantage by generating direct system-calls.) There might be a hodgepodge of methods and tools in userspace to do debugging, but in the kernel we should get our act together and only take _one_ (or none at all), and then spend all our efforts on improving that primary method of debug instrumentation. As kprobes/SystemTap has proven, it is possible to have zero-overhead inactive probes. Furthermore, for such a patch to make sense in the upstream kernel, downstream tracing code has to make actual use of that NOP-marker. I.e. a necessary (but not sufficient) requirement for upstream inclusion (in my view) would be for this mechanism to be used by LTT and LKST. (again, you can patch LTT for your own purposes in your own patchset if you think the performance overhead of probes is too much) 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/