From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932378AbZHYX2m (ORCPT ); Tue, 25 Aug 2009 19:28:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932312AbZHYX2m (ORCPT ); Tue, 25 Aug 2009 19:28:42 -0400 Received: from tomts40.bellnexxia.net ([209.226.175.97]:44375 "EHLO tomts40-srv.bellnexxia.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932315AbZHYX2l (ORCPT ); Tue, 25 Aug 2009 19:28:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooFAEcKlEpMROOX/2dsb2JhbACBU9cmhBoF Date: Tue, 25 Aug 2009 19:28:40 -0400 From: Mathieu Desnoyers To: Jason Baron Cc: Steven Rostedt , Frederic Weisbecker , linux-kernel@vger.kernel.org, x86@kernel.org, lethal@linux-sh.org, mingo@elte.hu, laijs@cn.fujitsu.com, peterz@infradead.org, jiayingz@google.com, mbligh@google.com, lizf@cn.fujitsu.com, jistone@redhat.com, tglx@linutronix.de, hpa@zytor.com Subject: Re: [PATCH 2/4] Add NR_syscalls for x86_64 Message-ID: <20090825232840.GA30362@Krystal> References: <233dfaa6fadd5aa2fa7ac8511ed9ab98a5f2619c.1251146513.git.jbaron@redhat.com> <20090824221447.GA5124@nowhere> <20090825134005.GB2656@redhat.com> <20090825184734.GE2656@redhat.com> <20090825190415.GB8474@Krystal> <20090825205829.GG2656@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <20090825205829.GG2656@redhat.com> X-Editor: vi X-Info: http://krystal.dyndns.org:8080 X-Operating-System: Linux/2.6.27.31-grsec (i686) X-Uptime: 19:19:50 up 7 days, 10:09, 2 users, load average: 0.37, 0.25, 0.25 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 * Jason Baron (jbaron@redhat.com) wrote: > On Tue, Aug 25, 2009 at 03:04:15PM -0400, Mathieu Desnoyers wrote: > > * Jason Baron (jbaron@redhat.com) wrote: > > > On Tue, Aug 25, 2009 at 09:40:05AM -0400, Jason Baron wrote: > > > > > > On Mon, Aug 24, 2009 at 05:40:18PM -0400, Jason Baron wrote: > > > > > > > Add a dynamic definition of NR_syscalls for x86_64. This is used in the > > > > > > > syscall events tracing code. > > > > > > > > > > > > > > Signed-off-by: Jason Baron > > > > > > > > > > > > > > --- > > > > > > > include/linux/ftrace.h | 5 +++++ > > > > > > > 1 files changed, 5 insertions(+), 0 deletions(-) > > > > > > > > > > > > > > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h > > > > > > > index dc3b132..3bd94ee 100644 > > > > > > > --- a/include/linux/ftrace.h > > > > > > > +++ b/include/linux/ftrace.h > > > > > > > @@ -14,6 +14,11 @@ > > > > > > > > > > > > > > #include > > > > > > > > > > > > > > +#ifdef CONFIG_X86_64 > > > > > > > +#include > > > > > > > +#define NR_syscalls (__NR_syscall_max + 1) > > > > > > > +#endif > > > > > > > + > > > > > > > > > > > > > > > > > > I'd rather see this in arch/x86/include/unistd_64.h, since > > > > > > NR_syscalls seems to be the defined in unistd.h in all archs. > > > > > > > > > > > > That also makes a unified way to retrieve this number for > > > > > > other users. > > > > > > > > > > > > > > > > Yes, NR_syscalls should be included there. > > > > > > > > > > -- Steve > > > > > > > > right, for x86_64, unistd.h is included to generate __NR_syscall_max > > > > which is then used for NR_syscalls. So I did initially try it there, but > > > > there were dependency problems. I'll see what I can come up with... > > > > > > > > thanks, > > > > > > > > -Jason > > > > > > ok, since unistd_64.h is used to generate offsets.c, which eventually > > > generates, asm/asm-offsets.h, which defines, __NR_syscall_max, we can't > > > just put #define of NR_syscalls in unistd_64.h. However, it seems the > > > only point in time that unistd_64.h can not depend upon __NR_syscall_max, > > > is before asm/asm-offsets.h is defined. Thus, the patch below passes in > > > a '-DCREATE_OFFSETS' during the creation of asm/asm-offsets.h, so that > > > we do not include it before it exists. The patch is hacky but works. > > > thoughts? > > > > Ugh! My eyes hurt! > > > > sorry :) > > > What you are doing here is to basically put back the hardcoded > > NR_syscalls rather that using the build infrastructure already in place. > > > > no. NR_syscalls is not hardcoded by this patch. Its defined in terms of > __NR_syscall_max which is dynamically generated by the kernel build. > > > If my memory serves me well, unistd_64.h generates __NR_syscall_max > > automatically by being included multiples times. Can we generalize this > > and make the information generated available in an automaticaly > > generated header instead ? It is saved in ams-offsets.h currently as > > "__NR_syscall_max". We could also save it somewhere else meant to be > > included by C code. > > > > Mathieu > > > > The request was to define NR_syscalls in unistd.h, since that is the > historical Linux location for it. Adding another automatically generated > header does not accomplish that. Even if I include that new file in > unistd.h, I'm still going to have a circular dependency, and require a > solution similar to what I've proposed. > OK, it may not be pretty, but it makes sense. :) Thanks, Mathieu > thanks, > > -Jason > -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68