Hi Arnd, On Mon, 19 Nov 2018 at 22:21, Arnd Bergmann <[email protected]> wrote: > > On Wed, Nov 14, 2018 at 5:32 AM Firoz Khan <[email protected]> wrote: > > > > NR_syscalls macro holds the number of system call exist > > in sh architecture. We have to change the value of NR- > > _syscalls, if we add or delete a system call. > > > > One of the patch in this patch series has a script which > > will generate a uapi header based on syscall.tbl file. > > The syscall.tbl file contains the total number of system > > calls information. So we have two option to update NR_sy- > > scalls value. > > > > 1. Update NR_syscalls in asm/unistd.h manually by count- > > ing the no.of system calls. No need to update NR_sys- > > calls until we either add a new system call or delete > > existing system call. > > > > 2. We can keep this feature it above mentioned script, > > that will count the number of syscalls and keep it in > > a generated file. In this case we don't need to expli- > > citly update NR_syscalls in asm/unistd.h file. > > > > The 2nd option will be the recommended one. For that, I > > added the __NR_syscalls macro in uapi/asm/unistd_32/64.h > > along with NR_syscalls which is moved to asm/unistd.h. > > The macro __NR_syscalls also added for making the name > > convention same across all architecture. While __NR_sys- > > calls isn't strictly part of the uapi, having it as part > > of the generated header to simplifies the implementation. > > We also need to enclose this macro with #ifdef __KERNEL__ > > to avoid side effects. > > > > Signed-off-by: Firoz Khan <[email protected]> > > Looks correct to me, but since there are only three references to > 'NR_syscalls' in arch/sh, I wonder if we should just replace it with > __NR_syscalls in the same patch.
This is the approach I had initially, But someone pointed out that doing this way - #define NR_syscalls __NR_syscalls would be better. The only difference is here the number of occurrence 3 and there 5-7 occurrence of NR_syscalls. Thanks Firoz > > Arnd _______________________________________________ Y2038 mailing list [email protected] https://lists.linaro.org/mailman/listinfo/y2038
