From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755940Ab0EGOyu (ORCPT ); Fri, 7 May 2010 10:54:50 -0400 Received: from tomts20-srv.bellnexxia.net ([209.226.175.74]:48928 "EHLO tomts20-srv.bellnexxia.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755533Ab0EGOys (ORCPT ); Fri, 7 May 2010 10:54:48 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACvG40tGGNqG/2dsb2JhbACeFnK/CYUVBA Date: Fri, 7 May 2010 10:54:38 -0400 From: Mathieu Desnoyers To: Frederic Weisbecker Cc: Steven Rostedt , linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton , Thomas Gleixner , Peter Zijlstra , Arnaldo Carvalho de Melo , Lai Jiangshan , Li Zefan , Masami Hiramatsu , Christoph Hellwig , "H. Peter Anvin" , Andi Kleen , "Paul E. McKenney" Subject: Re: [PATCH 3/9 - v2][RFC] tracing: Remove per event trace registering Message-ID: <20100507145438.GB29573@Krystal> References: <20100504034045.085822814@goodmis.org> <20100504034202.282030521@goodmis.org> <20100507042025.GC8069@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <20100507042025.GC8069@nowhere> X-Editor: vi X-Info: http://krystal.dyndns.org:8080 X-Operating-System: Linux/2.6.27.31-grsec (i686) X-Uptime: 10:42:20 up 30 days, 35 min, 3 users, load average: 0.19, 0.20, 0.18 User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Frederic Weisbecker (fweisbec@gmail.com) wrote: > On Mon, May 03, 2010 at 11:40:48PM -0400, Steven Rostedt wrote: > > From: Steven Rostedt > > > > This patch removes the register functions of TRACE_EVENT() to enable > > and disable tracepoints. The registering of a event is now down > > directly in the trace_events.c file. The tracepoint_probe_register() > > is now called directly. > > > > The prototypes are no longer type checked, but this should not be > > an issue since the tracepoints are created automatically by the > > macros. If a prototype is incorrect in the TRACE_EVENT() macro, then > > other macros will catch it. > > > > Agreed. Typechecking matters for human code but not in this context. > Considering that the tracepoint and the probe are created by the same > CPP code, bugs will be tracked down quickly and located to a single > place. So it seems that I am the only one asking for extra type-checking and caring about problems that can appear subtily on architectures where the number of caller/callee arguments must match. And also the only one considering that passing more arguments to a callback that does not expect all of them might be a problem on some architectures. Am I the only one thinking there is something fishy there ? I might be entirely over-paranoid, but this approach has rarely failed me in the past. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com