Re: [PATCH v2 01/16] Add __ASSUME_SYSVIPC_SYSCALL for Linux

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

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
>