| Message ID | 1543481016-18500-1-git-send-email-firoz.khan@linaro.org |
|---|---|
| Headers | show |
| Series | mips: system call table generation support | expand |
Hi Paul, On Thu, 29 Nov 2018 at 14:14, Firoz Khan <firoz.khan@linaro.org> wrote: > > The purpose of this patch series is, we can easily > add/modify/delete system call table support by cha- > nging entry in syscall.tbl file instead of manually > changing many files. The other goal is to unify the > system call table generation support implementation > across all the architectures. > > The system call tables are in different format in > all architecture. It will be difficult to manually > add, modify or delete the system calls in the resp- > ective files manually. To make it easy by keeping a > script and which'll generate uapi header file and > syscall table file. > > syscall.tbl contains the list of available system > calls along with system call number and correspond- > ing entry point. Add a new system call in this arch- > itecture will be possible by adding new entry in > the syscall.tbl file. > > Adding a new table entry consisting of: > - System call number. > - ABI. > - System call name. > - Entry point name. > - Compat entry name, if required. > > ARM, s390 and x86 architecuture does exist the sim- > ilar support. I leverage their implementation to > come up with a generic solution. > > I have done the same support for work for alpha, > ia64, m68k, microblaze, parisc, powerpc, sh, sparc, > and xtensa. Below mentioned git repository contains > more details about the workflow. > > https://github.com/frzkhn/system_call_table_generator/ > > Finally, this is the ground work to solve the Y2038 > issue. We need to add two dozen of system calls to > solve Y2038 issue. So this patch series will help to > add new system calls easily by adding new entry in > the syscall.tbl. > > Changes since v2: > - fixed __NR_syscalls assign issue. > > Changes since v1: > - optimized/updated the syscall table generation > scripts. > - fixed all mixed indentation issues in syscall.tbl. > - added "comments" in syscall_*.tbl. > - changed from generic-y to generated-y in Kbuild. > > Firoz Khan (6): > mips: add __NR_syscalls along with __NR_Linux_syscalls > mips: remove unused macros > mips: add +1 to __NR_syscalls in uapi header > mips: remove syscall table entries > mips: add system call table generation support > mips: generate uapi header and system call table files Could you review this patch series. I would appreciate if you can perform the boot test on the actual platform. Thanks Firoz > > arch/mips/Makefile | 3 + > arch/mips/include/asm/Kbuild | 4 + > arch/mips/include/asm/unistd.h | 8 - > arch/mips/include/uapi/asm/Kbuild | 6 + > arch/mips/include/uapi/asm/unistd.h | 1065 +---------------------------- > arch/mips/kernel/Makefile | 2 +- > arch/mips/kernel/ftrace.c | 8 +- > arch/mips/kernel/scall32-o32.S | 391 +---------- > arch/mips/kernel/scall64-64.S | 444 ------------ > arch/mips/kernel/scall64-n32.S | 341 +-------- > arch/mips/kernel/scall64-n64.S | 117 ++++ > arch/mips/kernel/scall64-o32.S | 379 +--------- > arch/mips/kernel/syscalls/Makefile | 96 +++ > arch/mips/kernel/syscalls/syscall_n32.tbl | 343 ++++++++++ > arch/mips/kernel/syscalls/syscall_n64.tbl | 339 +++++++++ > arch/mips/kernel/syscalls/syscall_o32.tbl | 382 +++++++++++ > arch/mips/kernel/syscalls/syscallhdr.sh | 36 + > arch/mips/kernel/syscalls/syscallnr.sh | 30 + > arch/mips/kernel/syscalls/syscalltbl.sh | 36 + > 19 files changed, 1430 insertions(+), 2600 deletions(-) > delete mode 100644 arch/mips/kernel/scall64-64.S > create mode 100644 arch/mips/kernel/scall64-n64.S > create mode 100644 arch/mips/kernel/syscalls/Makefile > create mode 100644 arch/mips/kernel/syscalls/syscall_n32.tbl > create mode 100644 arch/mips/kernel/syscalls/syscall_n64.tbl > create mode 100644 arch/mips/kernel/syscalls/syscall_o32.tbl > create mode 100644 arch/mips/kernel/syscalls/syscallhdr.sh > create mode 100644 arch/mips/kernel/syscalls/syscallnr.sh > create mode 100644 arch/mips/kernel/syscalls/syscalltbl.sh > > -- > 1.9.1 >
Hi Firoz, On Tue, Dec 04, 2018 at 09:33:08AM +0530, Firoz Khan wrote: > Could you review this patch series. I would appreciate if you can > perform the boot test on the actual platform. This is looking pretty good to me, so I look forward to v4 with Arnd's comments addressed. I've verified that the sys call tables are identical for both 32r2el_defconfig & 64r6el_defconfig before & after this series, and that both still boot fine. Thanks, Paul
Hi Paul, On Wed, 5 Dec 2018 at 12:04, Paul Burton <paul.burton@mips.com> wrote: > > Hi Firoz, > > On Tue, Dec 04, 2018 at 09:33:08AM +0530, Firoz Khan wrote: > > Could you review this patch series. I would appreciate if you can > > perform the boot test on the actual platform. > > This is looking pretty good to me, so I look forward to v4 with Arnd's > comments addressed. > > I've verified that the sys call tables are identical for both > 32r2el_defconfig & 64r6el_defconfig before & after this series, and that > both still boot fine. Great, thanks for the update. will send v4 asap. Firoz > > Thanks, > Paul
On Wed, 5 Dec 2018, Paul Burton wrote: > > Could you review this patch series. I would appreciate if you can > > perform the boot test on the actual platform. > > This is looking pretty good to me, so I look forward to v4 with Arnd's > comments addressed. > > I've verified that the sys call tables are identical for both > 32r2el_defconfig & 64r6el_defconfig before & after this series, and that > both still boot fine. I believe this file is used by the glibc build process to retrieve syscall numbers for glibc's own use as well for <sys/syscall.h>. Has the change been verified not to break this process? Cc-ing <libc-alpha@sourceware.org> for information and possible further input. Maciej
On Thu, 6 Dec 2018, Maciej W. Rozycki wrote: > I believe this file is used by the glibc build process to retrieve > syscall numbers for glibc's own use as well for <sys/syscall.h>. Has the > change been verified not to break this process? > > Cc-ing <libc-alpha@sourceware.org> for information and possible further > input. I'm not sure what "this file" is. The glibc build uses the installed <asm/unistd.h> (the results of #including it, not any other kind of processing the file). -- Joseph S. Myers joseph@codesourcery.com
On Thu, 6 Dec 2018, Joseph Myers wrote: > > I believe this file is used by the glibc build process to retrieve > > syscall numbers for glibc's own use as well for <sys/syscall.h>. Has the > > change been verified not to break this process? > > > > Cc-ing <libc-alpha@sourceware.org> for information and possible further > > input. > > I'm not sure what "this file" is. The glibc build uses the installed > <asm/unistd.h> (the results of #including it, not any other kind of > processing the file). So how are `SYS_<name>' macros generated that land in <bits/syscall.h>? Maciej
On Thu, 6 Dec 2018, Maciej W. Rozycki wrote: > On Thu, 6 Dec 2018, Joseph Myers wrote: > > > > I believe this file is used by the glibc build process to retrieve > > > syscall numbers for glibc's own use as well for <sys/syscall.h>. Has the > > > change been verified not to break this process? > > > > > > Cc-ing <libc-alpha@sourceware.org> for information and possible further > > > input. > > > > I'm not sure what "this file" is. The glibc build uses the installed > > <asm/unistd.h> (the results of #including it, not any other kind of > > processing the file). > > So how are `SYS_<name>' macros generated that land in <bits/syscall.h>? By gen-syscall-h.awk, which generates #ifdef conditionals for each possible __NR_* name (as listed in syscall-names.list in glibc). -- Joseph S. Myers joseph@codesourcery.com
On Thu, 6 Dec 2018, Joseph Myers wrote: > > So how are `SYS_<name>' macros generated that land in <bits/syscall.h>? > > By gen-syscall-h.awk, which generates #ifdef conditionals for each > possible __NR_* name (as listed in syscall-names.list in glibc). I seem to remember having to take extra care with how the three MIPS ABIs wire the syscalls to get it right in glibc, but I take it then this has been now addressed reliably enough for the glibc not to care how exactly <asm/unistd.h> has been arranged. Given my current level of involvement with the MIPS architecture I take your word for it and will not investigate it any further. Thanks for your input. Maciej
* Maciej W. Rozycki: > On Thu, 6 Dec 2018, Joseph Myers wrote: > >> > So how are `SYS_<name>' macros generated that land in <bits/syscall.h>? >> >> By gen-syscall-h.awk, which generates #ifdef conditionals for each >> possible __NR_* name (as listed in syscall-names.list in glibc). > > I seem to remember having to take extra care with how the three MIPS ABIs > wire the syscalls to get it right in glibc, but I take it then this has > been now addressed reliably enough for the glibc not to care how exactly > <asm/unistd.h> has been arranged. This is a fairly recent change (commit 2dba5ce7b8115d6a2789bf279892263621088e74, "<bits/syscall.h>: Use an arch-independent system call list on Linux", first release with it is glibc 2.27). This patch is quite backportable; we have put it into our 2.17-derived glibc, and the upstream work was originally driven by downstream ordering requirements of kernel header and glibc builds. Glad to see it's useful elsewhere. The test retains the old <asm/unistd.h>-based macro extraction for testing purposes, but it needs that only for the actual target architecture and only the *names*, so it's easy to implement. Before that, the generation would have to carefully take into account multiple sub-targets (i386/x86-64/x32 is one of the more complicated scenarios). Presumably, you saw problem with that part. Even if you introduce breakage here, it will only affect older glibc builds. It's not something that application developers would see. Thanks, Florian
On Thu, 6 Dec 2018, Florian Weimer wrote: > > I seem to remember having to take extra care with how the three MIPS ABIs > > wire the syscalls to get it right in glibc, but I take it then this has > > been now addressed reliably enough for the glibc not to care how exactly > > <asm/unistd.h> has been arranged. > > This is a fairly recent change (commit > 2dba5ce7b8115d6a2789bf279892263621088e74, "<bits/syscall.h>: Use an > arch-independent system call list on Linux", first release with it is > glibc 2.27). This patch is quite backportable; we have put it into our > 2.17-derived glibc, and the upstream work was originally driven by > downstream ordering requirements of kernel header and glibc builds. > Glad to see it's useful elsewhere. Thanks for the pointer, and the work you have done to make this more robust; it was that that I missed. > The test retains the old <asm/unistd.h>-based macro extraction for > testing purposes, but it needs that only for the actual target > architecture and only the *names*, so it's easy to implement. Before > that, the generation would have to carefully take into account multiple > sub-targets (i386/x86-64/x32 is one of the more complicated scenarios). > Presumably, you saw problem with that part. Yeah, the MIPS o32/n64/n32 ABI set is a corresponding situation, except that somewhat longer-lived as we've had support for these three ABIs since 2001, including the ability to concurrently run user executables built for any of these ABIs under a single 64-bit Linux kernel. Maciej
The purpose of this patch series is, we can easily add/modify/delete system call table support by cha- nging entry in syscall.tbl file instead of manually changing many files. The other goal is to unify the system call table generation support implementation across all the architectures. The system call tables are in different format in all architecture. It will be difficult to manually add, modify or delete the system calls in the resp- ective files manually. To make it easy by keeping a script and which'll generate uapi header file and syscall table file. syscall.tbl contains the list of available system calls along with system call number and correspond- ing entry point. Add a new system call in this arch- itecture will be possible by adding new entry in the syscall.tbl file. Adding a new table entry consisting of: - System call number. - ABI. - System call name. - Entry point name. - Compat entry name, if required. ARM, s390 and x86 architecuture does exist the sim- ilar support. I leverage their implementation to come up with a generic solution. I have done the same support for work for alpha, ia64, m68k, microblaze, parisc, powerpc, sh, sparc, and xtensa. Below mentioned git repository contains more details about the workflow. https://github.com/frzkhn/system_call_table_generator/ Finally, this is the ground work to solve the Y2038 issue. We need to add two dozen of system calls to solve Y2038 issue. So this patch series will help to add new system calls easily by adding new entry in the syscall.tbl. Changes since v2: - fixed __NR_syscalls assign issue. Changes since v1: - optimized/updated the syscall table generation scripts. - fixed all mixed indentation issues in syscall.tbl. - added "comments" in syscall_*.tbl. - changed from generic-y to generated-y in Kbuild. Firoz Khan (6): mips: add __NR_syscalls along with __NR_Linux_syscalls mips: remove unused macros mips: add +1 to __NR_syscalls in uapi header mips: remove syscall table entries mips: add system call table generation support mips: generate uapi header and system call table files arch/mips/Makefile | 3 + arch/mips/include/asm/Kbuild | 4 + arch/mips/include/asm/unistd.h | 8 - arch/mips/include/uapi/asm/Kbuild | 6 + arch/mips/include/uapi/asm/unistd.h | 1065 +---------------------------- arch/mips/kernel/Makefile | 2 +- arch/mips/kernel/ftrace.c | 8 +- arch/mips/kernel/scall32-o32.S | 391 +---------- arch/mips/kernel/scall64-64.S | 444 ------------ arch/mips/kernel/scall64-n32.S | 341 +-------- arch/mips/kernel/scall64-n64.S | 117 ++++ arch/mips/kernel/scall64-o32.S | 379 +--------- arch/mips/kernel/syscalls/Makefile | 96 +++ arch/mips/kernel/syscalls/syscall_n32.tbl | 343 ++++++++++ arch/mips/kernel/syscalls/syscall_n64.tbl | 339 +++++++++ arch/mips/kernel/syscalls/syscall_o32.tbl | 382 +++++++++++ arch/mips/kernel/syscalls/syscallhdr.sh | 36 + arch/mips/kernel/syscalls/syscallnr.sh | 30 + arch/mips/kernel/syscalls/syscalltbl.sh | 36 + 19 files changed, 1430 insertions(+), 2600 deletions(-) delete mode 100644 arch/mips/kernel/scall64-64.S create mode 100644 arch/mips/kernel/scall64-n64.S create mode 100644 arch/mips/kernel/syscalls/Makefile create mode 100644 arch/mips/kernel/syscalls/syscall_n32.tbl create mode 100644 arch/mips/kernel/syscalls/syscall_n64.tbl create mode 100644 arch/mips/kernel/syscalls/syscall_o32.tbl create mode 100644 arch/mips/kernel/syscalls/syscallhdr.sh create mode 100644 arch/mips/kernel/syscalls/syscallnr.sh create mode 100644 arch/mips/kernel/syscalls/syscalltbl.sh -- 1.9.1