Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 26 Aug 2009 01:38:35 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 2/4] Add NR_syscalls for x86_64 |
| |
On Tue, Aug 25, 2009 at 04:58:29PM -0400, Jason Baron wrote: > > 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. > > thanks, > > -Jason
Hmm, yeah that's not easy to deal with.
May be, to lower a bit the hacky impact of this patch, __NR_syscall_max should be at least replaced by NR_syscall in every x86-64 uses (also in asm-offsets.h), to standardize this variable name.
Also, may be we could have an empty asm-offsets.h stub in the very beginning that can be filled later so that we could include it unconditionnaly from unistd_64.h ?
It would be nice to have the opinion of an x86 maintainer about what to do.
| ![\](/images/icornerr.gif) |