| Message ID | 1539231895-4118-1-git-send-email-firoz.khan@linaro.org |
|---|---|
| Headers | show |
| Series | ia64: system call table generation support | expand |
Third time lucky. This series boots without any obvious errors on my ia64 machine. That's not and Ack or Review ... I just applied, compiled and booted. -Tony
Hi Tony, On Thu, 11 Oct 2018 at 22:59, Luck, Tony <tony.luck@intel.com> wrote: > > Third time lucky. This series boots without any obvious errors on my ia64 machine. Great! Thanks for your support! > > That's not and Ack or Review ... I just applied, compiled and booted. I suspect the offset logic in the system call generation script had a bug. That I fixed it in this patch series. Arnd and Eugene had shared few comments on adding new system call entry in the table and some other things. Appreciate if you can review this patch series so I can finalize system call table implementation for ia64 architecture. Firoz > > -Tony
> I suspect the offset logic in the system call generation script had a bug. That > I fixed it in this patch series. > > Arnd and Eugene had shared few comments on adding new system call entry in the > table and some other things. Appreciate if you can review this patch > series so I can > finalize system call table implementation for ia64 architecture. The net effect of these is just to make it easier to add new system calls. Just edit the table, instead of editing entry.S and unistd.h picking the next number (and remembering to increase the NR_syscalls). Right? I'm currently baffled at which linker magic makes the unsupported system calls alias to sys_ni_syscall. I'm also uncertain whether allocating system call numbers and creating entry points for all the unsupported syscalls is the right thing to do. Might that puzzle and frustrate folks whose applications build, but then fail at run-time with -ENOSYS. -Tony
On Fri, Oct 12, 2018 at 6:12 PM Luck, Tony <tony.luck@intel.com> wrote: > > > I suspect the offset logic in the system call generation script had a bug. That > > I fixed it in this patch series. > > > > Arnd and Eugene had shared few comments on adding new system call entry in the > > table and some other things. Appreciate if you can review this patch > > series so I can > > finalize system call table implementation for ia64 architecture. > > The net effect of these is just to make it easier to add new system calls. Just > edit the table, instead of editing entry.S and unistd.h picking the next number > (and remembering to increase the NR_syscalls). Right? The driving factor here is the addition of the new y2038 syscalls for 32-bit architectures that we want to add everywhere at the same time. ia64 and alpha are obviously not affected by this as they are 64-bit only, but to do it right, we should do all architectures together. Another point is overall maintainability: it is very time-consuming and error-prone to find out which architectures in which kernel version support a specific system call or don't support it. Having a consistent way to work on the tables should make this is a simple 'git grep'. > I'm currently baffled at which linker magic makes the unsupported system > calls alias to sys_ni_syscall. This is the same method that x86, arm, and s390 have been using for a while, by sorting the numbers and filling in the missing ones in the script. > I'm also uncertain whether allocating system call numbers and creating > entry points for all the unsupported syscalls is the right thing to do. Might > that puzzle and frustrate folks whose applications build, but then fail at > run-time with -ENOSYS. Again, we want this to be handled consistently across architectures more than anything. At the moment, we have some architectures that simply assign a number for each syscall added to x86, while others don't. Similarly, some architectures drop the entries from unistd.h if a syscall gets removed from the kernel, and others keep them. I care less about which way we decide to go here, but I want it to be done the same way for all architectures. Arnd
The purpose of this patch series is: 1. We can easily add/modify/delete system call by changing entry in syscall.tbl file. No need to manually edit many files. 2. It is easy to unify the system call implementation across all the architectures. The system call tables are in different format in all architecture and it will be difficult to manually add or modify the system calls in the respective files manually. To make it easy by keeping a script and which'll generate the header file and syscall table file so this change will unify them across all architectures. syscall.tbl contains the list of available system calls along with system call number and corresponding entry point. Add a new system call in this architecture 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 similar support. I leverage their implementation to come up with a generic solution. I have done the same support for work for alpha, microblaze, sparc, mips, parisc, powerpc, sh, sparc, and xtensa. But I started sending the patch for one architecuture for review. Below mentioned git repository contains more details. Git repo:- https://github.com/frzkhn/system_call_table_generator/ In v3 patch series, I wired up perf_event_open, seccomp, pkey_ mprotect, pkey_alloc, pkey_free, statx, io_pgetevents and rseq system calls. This require an architecture specific implementation as it not present now. Finally, this is the ground work for solving the Y2038 issue. We need to add/change two dozen of system calls to solve Y2038 issue. So this patch series will help to easily modify from existing system call to Y2038 compatible system calls. Firoz Khan (7): ia64: add __NR_old_getpagesize in uapi/asm/unistd.h ia64: replace NR_syscalls macro from asm/unistd.h ia64: add an offset for system call number ia64: replace the system call table entries from entry.S ia64: add system call table generation support ia64: uapi header and system call table file generation ia64: wire up system calls arch/ia64/Makefile | 3 + arch/ia64/include/asm/Kbuild | 1 + arch/ia64/include/asm/unistd.h | 4 +- arch/ia64/include/uapi/asm/Kbuild | 1 + arch/ia64/include/uapi/asm/unistd.h | 332 +----------------------------- arch/ia64/kernel/entry.S | 333 +----------------------------- arch/ia64/kernel/syscall_table.S | 9 + arch/ia64/kernel/syscalls/Makefile | 39 ++++ arch/ia64/kernel/syscalls/syscall.tbl | 353 ++++++++++++++++++++++++++++++++ arch/ia64/kernel/syscalls/syscallhdr.sh | 35 ++++ arch/ia64/kernel/syscalls/syscalltbl.sh | 37 ++++ 11 files changed, 483 insertions(+), 664 deletions(-) create mode 100644 arch/ia64/kernel/syscall_table.S create mode 100644 arch/ia64/kernel/syscalls/Makefile create mode 100644 arch/ia64/kernel/syscalls/syscall.tbl create mode 100644 arch/ia64/kernel/syscalls/syscallhdr.sh create mode 100644 arch/ia64/kernel/syscalls/syscalltbl.sh -- 1.9.1