This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 01/16] Add __ASSUME_SYSVIPC_SYSCALL for Linux
On Wednesday, November 2, 2016 5:26:38 PM CET Adhemerval Zanella wrote:
> The architectures that only supports ipc syscall are:
> - i386, m68k, microblaze, mips32, powerpc (powerpc32, powerpc64, and
> powerpc64le), s390 (32 and 64 bits), sh, sparc32, and sparc64.
If you want to mention the architectures not supported by glibc, this
also includes
cris, frv, m32r, and mn10300
> And the architectures that only supports wired syscalls are:
> - aarch64, alpha, hppa, ia64, mips64, mips64n32, nios2, tile
> (tilepro, tilegx, and tilegx64), and x86_64
similarly, this also includes
arc, avr32, blackfin, c6x, h8300, hexagon, metag, openrisc, score,
unicore32, and xtensa
> Also arm is the only one that supports both wire syscalls and the
> ipc, although the ipc one is deprecated.
AFAICT, ipc syscall on ARM is only defined for OABI, which glibc
no longer has.
>From the kernel sources, I also see sh64 and microblaze define
both __NR_ipc and the individual numbers, although microblaze
returns -ENOSYS for ipc().
> This patch adds a new define, __ASSUME_SYSVIPC_SYSCALL, that wired
> syscalls are supported on the system and the general idea is to use
> it where possible.
We might add the individual syscalls on all architectures at some point
in the kernel, including the ones that currently use the combined
ipc call. A patch series for this has been discussed in the past,
but I think we never fully resolved the handling of the IPC_64
flag, so it did not get merged so far.
With your current approach, this won't cause problems as architectures
that don't have the individual calls with old kernel versions will
still use the ipc() wrapper in the kernel.
Arnd