| Message ID | 1533791723-3882-3-git-send-email-firoz.khan@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | System call table generation support | expand |
Hi Firoz, One first comment below... On Thu, Aug 9, 2018 at 7:16 AM Firoz Khan <firoz.khan@linaro.org> wrote: > NR_syscalls macro holds the number of system call exist in m68k > architecture. This macro is currently the part of asm/unistd.h file. > We have to change the value of NR_syscalls, if we add or delete a > system call. > > One of 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 number of system call information. So we have two > option to update NR_syscalls value. > > 1. Update NR_syscalls in asm/unistd.h manually by counting the > no.of system calls. No need to update NR_syscalls untill > we either add a new system call or delete an existing system > call. > > 2. We can keep this feature it above mentioned script, that'll > count the number of syscalls and keep it in a generated file. > In this case we don't need to explicitly update NR_syscalls > in asm/unistd.h file. > > The 2nd option will be the recommended one. For that, I moved the > NR_syscalls macro from asm/unistd.h to uapi/asm/unistd.h. The macro > name also changed form NR_syscalls to __NR_syscalls for making the > name convention same across all architecture. While __NR_syscalls > isn't strictly part of the uapi, having it as part of the generated > header to simplifies the implementation. It can indeed not be part of the UAPI, as UAPI definitions can never change, while new syscalls will be added in the future, increasing the number ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On 9 August 2018 at 13:00, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Firoz, > > One first comment below... > > On Thu, Aug 9, 2018 at 7:16 AM Firoz Khan <firoz.khan@linaro.org> wrote: >> NR_syscalls macro holds the number of system call exist in m68k >> architecture. This macro is currently the part of asm/unistd.h file. >> We have to change the value of NR_syscalls, if we add or delete a >> system call. >> >> One of 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 number of system call information. So we have two >> option to update NR_syscalls value. >> >> 1. Update NR_syscalls in asm/unistd.h manually by counting the >> no.of system calls. No need to update NR_syscalls untill >> we either add a new system call or delete an existing system >> call. >> >> 2. We can keep this feature it above mentioned script, that'll >> count the number of syscalls and keep it in a generated file. >> In this case we don't need to explicitly update NR_syscalls >> in asm/unistd.h file. >> >> The 2nd option will be the recommended one. For that, I moved the >> NR_syscalls macro from asm/unistd.h to uapi/asm/unistd.h. The macro >> name also changed form NR_syscalls to __NR_syscalls for making the >> name convention same across all architecture. While __NR_syscalls >> isn't strictly part of the uapi, having it as part of the generated >> header to simplifies the implementation. > > It can indeed not be part of the UAPI, as UAPI definitions can never change, > while new syscalls will be added in the future, increasing the number ;-) Thanks for your reply :) Sorry for the delayed response :( I would like to keep __NR_syscalls macro to uapi header in order to simplify the system call table generation script. Otherwise the __NR_syscalls macro need to update manually. That become a problem. Please check the below implementation in uapi file make sense? It is an easy workaround to leave __NR_syscalls macro in uapi/asm/unistd.h and enclose it in #ifdef __KERNEL__ ... ... #define __NR_pwritev2 378 #define __NR_statx 379 #ifdef __KERNEL__ #define __NR_syscalls 380 #endif ... ... > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
Hi Firoz, On Tue, Sep 18, 2018 at 9:16 AM Firoz Khan <firoz.khan@linaro.org> wrote: > On 9 August 2018 at 13:00, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > One first comment below... > > > > On Thu, Aug 9, 2018 at 7:16 AM Firoz Khan <firoz.khan@linaro.org> wrote: > >> NR_syscalls macro holds the number of system call exist in m68k > >> architecture. This macro is currently the part of asm/unistd.h file. > >> We have to change the value of NR_syscalls, if we add or delete a > >> system call. > >> > >> One of 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 number of system call information. So we have two > >> option to update NR_syscalls value. > >> > >> 1. Update NR_syscalls in asm/unistd.h manually by counting the > >> no.of system calls. No need to update NR_syscalls untill > >> we either add a new system call or delete an existing system > >> call. > >> > >> 2. We can keep this feature it above mentioned script, that'll > >> count the number of syscalls and keep it in a generated file. > >> In this case we don't need to explicitly update NR_syscalls > >> in asm/unistd.h file. > >> > >> The 2nd option will be the recommended one. For that, I moved the > >> NR_syscalls macro from asm/unistd.h to uapi/asm/unistd.h. The macro > >> name also changed form NR_syscalls to __NR_syscalls for making the > >> name convention same across all architecture. While __NR_syscalls > >> isn't strictly part of the uapi, having it as part of the generated > >> header to simplifies the implementation. > > > > It can indeed not be part of the UAPI, as UAPI definitions can never change, > > while new syscalls will be added in the future, increasing the number ;-) > > Thanks for your reply :) > Sorry for the delayed response :( > > I would like to keep __NR_syscalls macro to uapi header in order to simplify > the system call table generation script. Otherwise the __NR_syscalls > macro need to update manually. That become a problem. > > Please check the below implementation in uapi file make sense? > It is an easy workaround to leave __NR_syscalls macro in uapi/asm/unistd.h > and enclose it in #ifdef __KERNEL__ > > ... > ... > #define __NR_pwritev2 378 > #define __NR_statx 379 > > #ifdef __KERNEL__ > #define __NR_syscalls 380 > #endif > ... > ... #ifdef __KERNEL__ sounds fine to me. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On 18 September 2018 at 15:34, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Firoz, > > On Tue, Sep 18, 2018 at 9:16 AM Firoz Khan <firoz.khan@linaro.org> wrote: >> On 9 August 2018 at 13:00, Geert Uytterhoeven <geert@linux-m68k.org> wrote: >> > One first comment below... >> > >> > On Thu, Aug 9, 2018 at 7:16 AM Firoz Khan <firoz.khan@linaro.org> wrote: >> >> NR_syscalls macro holds the number of system call exist in m68k >> >> architecture. This macro is currently the part of asm/unistd.h file. >> >> We have to change the value of NR_syscalls, if we add or delete a >> >> system call. >> >> >> >> One of 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 number of system call information. So we have two >> >> option to update NR_syscalls value. >> >> >> >> 1. Update NR_syscalls in asm/unistd.h manually by counting the >> >> no.of system calls. No need to update NR_syscalls untill >> >> we either add a new system call or delete an existing system >> >> call. >> >> >> >> 2. We can keep this feature it above mentioned script, that'll >> >> count the number of syscalls and keep it in a generated file. >> >> In this case we don't need to explicitly update NR_syscalls >> >> in asm/unistd.h file. >> >> >> >> The 2nd option will be the recommended one. For that, I moved the >> >> NR_syscalls macro from asm/unistd.h to uapi/asm/unistd.h. The macro >> >> name also changed form NR_syscalls to __NR_syscalls for making the >> >> name convention same across all architecture. While __NR_syscalls >> >> isn't strictly part of the uapi, having it as part of the generated >> >> header to simplifies the implementation. >> > >> > It can indeed not be part of the UAPI, as UAPI definitions can never change, >> > while new syscalls will be added in the future, increasing the number ;-) >> >> Thanks for your reply :) >> Sorry for the delayed response :( >> >> I would like to keep __NR_syscalls macro to uapi header in order to simplify >> the system call table generation script. Otherwise the __NR_syscalls >> macro need to update manually. That become a problem. >> >> Please check the below implementation in uapi file make sense? >> It is an easy workaround to leave __NR_syscalls macro in uapi/asm/unistd.h >> and enclose it in #ifdef __KERNEL__ >> >> ... >> ... >> #define __NR_pwritev2 378 >> #define __NR_statx 379 >> >> #ifdef __KERNEL__ >> #define __NR_syscalls 380 >> #endif >> ... >> ... > > #ifdef __KERNEL__ sounds fine to me. Thanks for the reply. I'll post v2 patches ASAP with this changes. - Firoz > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
Hi Geert, On 18 September 2018 at 15:34, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Firoz, > > On Tue, Sep 18, 2018 at 9:16 AM Firoz Khan <firoz.khan@linaro.org> wrote: >> On 9 August 2018 at 13:00, Geert Uytterhoeven <geert@linux-m68k.org> wrote: >> > One first comment below... >> > >> > On Thu, Aug 9, 2018 at 7:16 AM Firoz Khan <firoz.khan@linaro.org> wrote: >> >> NR_syscalls macro holds the number of system call exist in m68k >> >> architecture. This macro is currently the part of asm/unistd.h file. >> >> We have to change the value of NR_syscalls, if we add or delete a >> >> system call. >> >> >> >> One of 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 number of system call information. So we have two >> >> option to update NR_syscalls value. >> >> >> >> 1. Update NR_syscalls in asm/unistd.h manually by counting the >> >> no.of system calls. No need to update NR_syscalls untill >> >> we either add a new system call or delete an existing system >> >> call. >> >> >> >> 2. We can keep this feature it above mentioned script, that'll >> >> count the number of syscalls and keep it in a generated file. >> >> In this case we don't need to explicitly update NR_syscalls >> >> in asm/unistd.h file. >> >> >> >> The 2nd option will be the recommended one. For that, I moved the >> >> NR_syscalls macro from asm/unistd.h to uapi/asm/unistd.h. The macro >> >> name also changed form NR_syscalls to __NR_syscalls for making the >> >> name convention same across all architecture. While __NR_syscalls >> >> isn't strictly part of the uapi, having it as part of the generated >> >> header to simplifies the implementation. >> > >> > It can indeed not be part of the UAPI, as UAPI definitions can never change, >> > while new syscalls will be added in the future, increasing the number ;-) >> >> Thanks for your reply :) >> Sorry for the delayed response :( >> >> I would like to keep __NR_syscalls macro to uapi header in order to simplify >> the system call table generation script. Otherwise the __NR_syscalls >> macro need to update manually. That become a problem. >> >> Please check the below implementation in uapi file make sense? >> It is an easy workaround to leave __NR_syscalls macro in uapi/asm/unistd.h >> and enclose it in #ifdef __KERNEL__ >> >> ... >> ... >> #define __NR_pwritev2 378 >> #define __NR_statx 379 >> >> #ifdef __KERNEL__ >> #define __NR_syscalls 380 >> #endif >> ... >> ... > > #ifdef __KERNEL__ sounds fine to me. I posted similar script for 10 different architectures. I got few good review from the maintainers and it will be applicable for all the architectures including m68k. There are few area which I identified need to improve. This will take couple of days. But it will be very helpful if you can perform the boot test on the actual platform and share the result. FYI, Keeping a single script is always our plan for long run. But I have to keep a separate versions for the start so each architecture can be handled in one series. Which would make easier to merge in the initial version. we could probably add it to scripts/*.sh first, but that requires more coordination between the architectures. - Firoz > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
Hi Firoz, On Thu, Sep 20, 2018 at 10:12 AM Firoz Khan <firoz.khan@linaro.org> wrote: > On 18 September 2018 at 15:34, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Tue, Sep 18, 2018 at 9:16 AM Firoz Khan <firoz.khan@linaro.org> wrote: > >> On 9 August 2018 at 13:00, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > >> > One first comment below... > >> > > >> > On Thu, Aug 9, 2018 at 7:16 AM Firoz Khan <firoz.khan@linaro.org> wrote: > >> >> NR_syscalls macro holds the number of system call exist in m68k > >> >> architecture. This macro is currently the part of asm/unistd.h file. > >> >> We have to change the value of NR_syscalls, if we add or delete a > >> >> system call. > >> >> > >> >> One of 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 number of system call information. So we have two > >> >> option to update NR_syscalls value. > >> >> > >> >> 1. Update NR_syscalls in asm/unistd.h manually by counting the > >> >> no.of system calls. No need to update NR_syscalls untill > >> >> we either add a new system call or delete an existing system > >> >> call. > >> >> > >> >> 2. We can keep this feature it above mentioned script, that'll > >> >> count the number of syscalls and keep it in a generated file. > >> >> In this case we don't need to explicitly update NR_syscalls > >> >> in asm/unistd.h file. > >> >> > >> >> The 2nd option will be the recommended one. For that, I moved the > >> >> NR_syscalls macro from asm/unistd.h to uapi/asm/unistd.h. The macro > >> >> name also changed form NR_syscalls to __NR_syscalls for making the > >> >> name convention same across all architecture. While __NR_syscalls > >> >> isn't strictly part of the uapi, having it as part of the generated > >> >> header to simplifies the implementation. > >> > > >> > It can indeed not be part of the UAPI, as UAPI definitions can never change, > >> > while new syscalls will be added in the future, increasing the number ;-) > >> > >> Thanks for your reply :) > >> Sorry for the delayed response :( > >> > >> I would like to keep __NR_syscalls macro to uapi header in order to simplify > >> the system call table generation script. Otherwise the __NR_syscalls > >> macro need to update manually. That become a problem. > >> > >> Please check the below implementation in uapi file make sense? > >> It is an easy workaround to leave __NR_syscalls macro in uapi/asm/unistd.h > >> and enclose it in #ifdef __KERNEL__ > >> > >> ... > >> ... > >> #define __NR_pwritev2 378 > >> #define __NR_statx 379 > >> > >> #ifdef __KERNEL__ > >> #define __NR_syscalls 380 > >> #endif > >> ... > >> ... > > > > #ifdef __KERNEL__ sounds fine to me. > > I posted similar script for 10 different architectures. I got few good review > from the maintainers and it will be applicable for all the > architectures including > m68k. There are few area which I identified need to improve. This will take > couple of days. > > But it will be very helpful if you can perform the boot test on the > actual platform > and share the result. Builds and boots fine on ARAnyM (virtual Atari). So for the full series: Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> However, I noticed the following effective difference between the old arch/m68k/include/uapi/asm/unistd.h and the new generated arch/m68k/include/generated/uapi/asm/unistd_32.h: -/*#define __NR_break 17*/ -/*#define __NR_stty 31*/ -/*#define __NR_gtty 32*/ -/*#define __NR_ftime 35*/ -/*#define __NR_prof 44*/ -/*#define __NR_lock 53*/ -/*#define __NR_mpx 56*/ -/*#define __NR_ulimit 58*/ -/*#define __NR_oldolduname 59*/ -/*#define __NR_profil 98*/ -/*#define __NR_ioperm 101*/ -/*#define __NR_olduname 109*/ -/*#define __NR_iopl 110*/ /* not supported */ -/*#define __NR_idle 112*/ /* Obsolete */ -/*#define __NR_vm86 113*/ /* not supported */ -/*#define __NR_afs_syscall 137*/ /* Syscall for Andrew File System */ -/*#define __NR_vserver 278*/ +#define __NR_break 17 +#define __NR_stty 31 +#define __NR_gtty 32 +#define __NR_ftime 35 +#define __NR_prof 44 +#define __NR_lock 53 +#define __NR_mpx 56 +#define __NR_ulimit 58 +#define __NR_oldolduname 59 +#define __NR_profil 98 +#define __NR_ioperm 101 +#define __NR_olduname 109 +#define __NR_iopl 110 +#define __NR_idle 112 +#define __NR_vm86 113 +#define __NR_afs_syscall 137 +#define __NR_vserver 278 Given userspace code may contain checks for the presence of these defines, I think they should not be present. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, On Thu, 20 Sep 2018 at 14:54, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Firoz, > > On Thu, Sep 20, 2018 at 10:12 AM Firoz Khan <firoz.khan@linaro.org> wrote: > > On 18 September 2018 at 15:34, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Tue, Sep 18, 2018 at 9:16 AM Firoz Khan <firoz.khan@linaro.org> wrote: > > >> On 9 August 2018 at 13:00, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > >> > One first comment below... > > >> > > > >> > On Thu, Aug 9, 2018 at 7:16 AM Firoz Khan <firoz.khan@linaro.org> wrote: > > >> >> NR_syscalls macro holds the number of system call exist in m68k > > >> >> architecture. This macro is currently the part of asm/unistd.h file. > > >> >> We have to change the value of NR_syscalls, if we add or delete a > > >> >> system call. > > >> >> > > >> >> One of 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 number of system call information. So we have two > > >> >> option to update NR_syscalls value. > > >> >> > > >> >> 1. Update NR_syscalls in asm/unistd.h manually by counting the > > >> >> no.of system calls. No need to update NR_syscalls untill > > >> >> we either add a new system call or delete an existing system > > >> >> call. > > >> >> > > >> >> 2. We can keep this feature it above mentioned script, that'll > > >> >> count the number of syscalls and keep it in a generated file. > > >> >> In this case we don't need to explicitly update NR_syscalls > > >> >> in asm/unistd.h file. > > >> >> > > >> >> The 2nd option will be the recommended one. For that, I moved the > > >> >> NR_syscalls macro from asm/unistd.h to uapi/asm/unistd.h. The macro > > >> >> name also changed form NR_syscalls to __NR_syscalls for making the > > >> >> name convention same across all architecture. While __NR_syscalls > > >> >> isn't strictly part of the uapi, having it as part of the generated > > >> >> header to simplifies the implementation. > > >> > > > >> > It can indeed not be part of the UAPI, as UAPI definitions can never change, > > >> > while new syscalls will be added in the future, increasing the number ;-) > > >> > > >> Thanks for your reply :) > > >> Sorry for the delayed response :( > > >> > > >> I would like to keep __NR_syscalls macro to uapi header in order to simplify > > >> the system call table generation script. Otherwise the __NR_syscalls > > >> macro need to update manually. That become a problem. > > >> > > >> Please check the below implementation in uapi file make sense? > > >> It is an easy workaround to leave __NR_syscalls macro in uapi/asm/unistd.h > > >> and enclose it in #ifdef __KERNEL__ > > >> > > >> ... > > >> ... > > >> #define __NR_pwritev2 378 > > >> #define __NR_statx 379 > > >> > > >> #ifdef __KERNEL__ > > >> #define __NR_syscalls 380 > > >> #endif > > >> ... > > >> ... > > > > > > #ifdef __KERNEL__ sounds fine to me. > > > > I posted similar script for 10 different architectures. I got few good review > > from the maintainers and it will be applicable for all the > > architectures including > > m68k. There are few area which I identified need to improve. This will take > > couple of days. > > > > But it will be very helpful if you can perform the boot test on the > > actual platform > > and share the result. > > Builds and boots fine on ARAnyM (virtual Atari). Thanks for the support :) > > So for the full series: > Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> > > However, I noticed the following effective difference between the old > arch/m68k/include/uapi/asm/unistd.h and the new generated > arch/m68k/include/generated/uapi/asm/unistd_32.h: > > -/*#define __NR_break 17*/ > -/*#define __NR_stty 31*/ > -/*#define __NR_gtty 32*/ > -/*#define __NR_ftime 35*/ > -/*#define __NR_prof 44*/ > -/*#define __NR_lock 53*/ > -/*#define __NR_mpx 56*/ > -/*#define __NR_ulimit 58*/ > -/*#define __NR_oldolduname 59*/ > -/*#define __NR_profil 98*/ > -/*#define __NR_ioperm 101*/ > -/*#define __NR_olduname 109*/ > -/*#define __NR_iopl 110*/ /* not supported */ > -/*#define __NR_idle 112*/ /* Obsolete */ > -/*#define __NR_vm86 113*/ /* not supported */ > -/*#define __NR_afs_syscall 137*/ /* Syscall for Andrew File System */ > -/*#define __NR_vserver 278*/ > +#define __NR_break 17 > +#define __NR_stty 31 > +#define __NR_gtty 32 > +#define __NR_ftime 35 > +#define __NR_prof 44 > +#define __NR_lock 53 > +#define __NR_mpx 56 > +#define __NR_ulimit 58 > +#define __NR_oldolduname 59 > +#define __NR_profil 98 > +#define __NR_ioperm 101 > +#define __NR_olduname 109 > +#define __NR_iopl 110 > +#define __NR_idle 112 > +#define __NR_vm86 113 > +#define __NR_afs_syscall 137 > +#define __NR_vserver 278 > > Given userspace code may contain checks for the presence of these > defines, I think they should not be present. My patch series had some different way to handle the above one. Some how the plan got changed and missed it :( I posted v2 patch series Thursday evening. This contain some modi- fications suggested by different architecture maintainers including you. Please help us to review the patch series and please perform boot test on the actual platform. Thanks Firoz > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
diff --git a/arch/m68k/68000/entry.S b/arch/m68k/68000/entry.S index 259b366..91522e9 100644 --- a/arch/m68k/68000/entry.S +++ b/arch/m68k/68000/entry.S @@ -49,7 +49,7 @@ do_trace: addql #4,%sp movel %sp@(PT_OFF_ORIG_D0),%d1 movel #-ENOSYS,%d0 - cmpl #NR_syscalls,%d1 + cmpl #__NR_syscalls,%d1 jcc 1f lsl #2,%d1 lea sys_call_table, %a0 @@ -80,7 +80,7 @@ ENTRY(system_call) movel %d1,%a2 btst #(TIF_SYSCALL_TRACE%8),%a2@(TINFO_FLAGS+(31-TIF_SYSCALL_TRACE)/8) jne do_trace - cmpl #NR_syscalls,%d0 + cmpl #__NR_syscalls,%d0 jcc badsys lsl #2,%d0 lea sys_call_table,%a0 diff --git a/arch/m68k/coldfire/entry.S b/arch/m68k/coldfire/entry.S index 52d312d..efe777d 100644 --- a/arch/m68k/coldfire/entry.S +++ b/arch/m68k/coldfire/entry.S @@ -64,7 +64,7 @@ ENTRY(system_call) move #0x2000,%sr /* enable intrs again */ GET_CURRENT(%d2) - cmpl #NR_syscalls,%d0 + cmpl #__NR_syscalls,%d0 jcc enosys lea sys_call_table,%a0 lsll #2,%d0 /* movel %a0@(%d0:l:4),%d3 */ diff --git a/arch/m68k/include/asm/unistd.h b/arch/m68k/include/asm/unistd.h index 30d0d3f..52111fb 100644 --- a/arch/m68k/include/asm/unistd.h +++ b/arch/m68k/include/asm/unistd.h @@ -4,9 +4,6 @@ #include <uapi/asm/unistd.h> - -#define NR_syscalls 380 - #define __ARCH_WANT_OLD_READDIR #define __ARCH_WANT_OLD_STAT #define __ARCH_WANT_STAT64 diff --git a/arch/m68k/include/uapi/asm/unistd.h b/arch/m68k/include/uapi/asm/unistd.h index de3054f..b17ae53 100644 --- a/arch/m68k/include/uapi/asm/unistd.h +++ b/arch/m68k/include/uapi/asm/unistd.h @@ -387,4 +387,6 @@ #define __NR_pwritev2 378 #define __NR_statx 379 +#define __NR_syscalls 380 + #endif /* _UAPI_ASM_M68K_UNISTD_H_ */ diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S index 97cd3ea..dab0cfd 100644 --- a/arch/m68k/kernel/entry.S +++ b/arch/m68k/kernel/entry.S @@ -161,7 +161,7 @@ do_trace_entry: RESTORE_SWITCH_STACK addql #4,%sp movel %sp@(PT_OFF_ORIG_D0),%d0 - cmpl #NR_syscalls,%d0 + cmpl #__NR_syscalls,%d0 jcs syscall badsys: movel #-ENOSYS,%sp@(PT_OFF_D0) @@ -206,7 +206,7 @@ ENTRY(system_call) | syscall trace? tstb %a1@(TINFO_FLAGS+2) jmi do_trace_entry - cmpl #NR_syscalls,%d0 + cmpl #__NR_syscalls,%d0 jcc badsys syscall: jbsr @(sys_call_table,%d0:l:4)@(0)
NR_syscalls macro holds the number of system call exist in m68k architecture. This macro is currently the part of asm/unistd.h file. We have to change the value of NR_syscalls, if we add or delete a system call. One of 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 number of system call information. So we have two option to update NR_syscalls value. 1. Update NR_syscalls in asm/unistd.h manually by counting the no.of system calls. No need to update NR_syscalls untill we either add a new system call or delete an existing system call. 2. We can keep this feature it above mentioned script, that'll count the number of syscalls and keep it in a generated file. In this case we don't need to explicitly update NR_syscalls in asm/unistd.h file. The 2nd option will be the recommended one. For that, I moved the NR_syscalls macro from asm/unistd.h to uapi/asm/unistd.h. The macro name also changed form NR_syscalls to __NR_syscalls for making the name convention same across all architecture. While __NR_syscalls isn't strictly part of the uapi, having it as part of the generated header to simplifies the implementation. Signed-off-by: Firoz Khan <firoz.khan@linaro.org> --- arch/m68k/68000/entry.S | 4 ++-- arch/m68k/coldfire/entry.S | 2 +- arch/m68k/include/asm/unistd.h | 3 --- arch/m68k/include/uapi/asm/unistd.h | 2 ++ arch/m68k/kernel/entry.S | 4 ++-- 5 files changed, 7 insertions(+), 8 deletions(-) -- 1.9.1