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@arndb.de>
---
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 <redacted>