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 07/11/2016 09:28, Arnd Bergmann wrote:
> 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
>
I think for commit/code comment mentioning only the supported archs
should be suffice.
>> 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.
Indeed, I think I should note that glibc's supported arm eabi should
use wire syscalls (although for a source standpoint it will still
see __NR_ipc defined).
>
> From the kernel sources, I also see sh64 and microblaze define
> both __NR_ipc and the individual numbers, although microblaze
> returns -ENOSYS for ipc().
Indeed, in my first analysis I did not filter 'sys_ni_syscall' while
checking the syscall table in kernel files. With this checked
microblaze should that ipc is defined as 'sys_ni_syscall'.
>
>> 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.
>
That's the idea and if a architecture eventually adds wire ipc support
it just need to correct undefine __ASSUME_SYSVIPC_SYSCALL within correct
kernel header version.
>
> Arnd
>