On Fri, Jan 18, 2019 at 05:18:19PM +0100, Arnd Bergmann wrote:
The IPC system call handling is highly inconsistent across architectures, some use sys_ipc, some use separate calls, and some use both. We also have some architectures that require passing IPC_64 in the flags, and others that set it implicitly. For the additon of a y2083 safe semtimedop() system call, I chose to only support the separate entry points, but that requires first supporting the regular ones with their own syscall numbers. The IPC_64 is now implied by the new semctl/shmctl/msgctl system calls even on the architectures that require passing it with the ipc() multiplexer. I'm not adding the new semtimedop() or semop() on 32-bit architectures, those will get implemented using the new semtimedop_time64() version that gets added along with the other time64 calls. Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop(). Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx> --- One aspect here that might be a bit controversial is the use of the same system call numbers across all architectures, synchronizing all of them with the x86-32 numbers. With the new syscall.tbl files, I hope we can just keep doing that in the future, and no longer require the architecture maintainers to assign a number. This is mainly useful for implementers of the C libraries: if we can add future system calls everywhere at the same time, using a particular version of the kernel headers also guarantees that the system call number macro is visible. --- arch/m68k/kernel/syscalls/syscall.tbl | 11 +++++++++++ arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++++++++++ arch/powerpc/kernel/syscalls/syscall.tbl | 13 +++++++++++++ arch/s390/kernel/syscalls/syscall.tbl | 12 ++++++++++++ arch/sh/kernel/syscalls/syscall.tbl | 11 +++++++++++ arch/sparc/kernel/syscalls/syscall.tbl | 12 ++++++++++++ arch/x86/entry/syscalls/syscall_32.tbl | 11 +++++++++++ 7 files changed, 81 insertions(+)
For the s390 bits: Acked-by: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
