[PATCH 00/28] More Linux syscall refactor

[Adhemerval Zanella]

On 18/11/2020 18:06, Joseph Myers wrote:
> This series introduces assumptions that various socket syscalls are 
> available.  That's not valid until the minimum Linux kernel version has 
> been increased to at least 4.4 (depending on the architecture, but 
> probably such a change would be done globally).  In the case of 
> getpeername and getsockname, at least, it's not safe (for 32-bit SPARC 
> under 64-bit kernels) until Linux 4.20 - in general, before assuming a 
> syscall to be present after any increase of the minimum Linux kernel 
> version, it's important to review the actual state of support for that 
> syscall in the minimum kernel version, including in compat syscall tables.

The idea of this socket changes is to align with default Linux kernel ABI,
to make the outliers to explicit disable the syscall support where 
applicable and simplify the relation netweenn the syscalls.list and the 
required C implementations.

The 'bind', for instance, is not listed on sysdeps/unix/sysv/linux/syscalls.list,
so ports that do not imply on 'generic' will need to explicit disable on
the kernel-features.h.  Another idea of this change it to eventually
remove the sysdeps/unix/sysv/linux/generic/ and make 
sysdeps/unix/sysv/linux the default implementation.

And the idea is not change any current assumption, my goal is just reorganize
the code. For getpeername and getsockname is indeed wrong assumption in my
patch, it should disable both for !__arch64__ && __LINUX_KERNEL_VERSION < 0x040400.

> 
> As I previously noted 
> <https://sourceware.org/pipermail/libc-alpha/2020-July/116453.html>, I 
> think we ought to implement Carlos's proposal of removing the runtime 
> check for old kernel versions before increasing the minimum kernel 
> version, given that an increased version allows very little cleanup for 
> e.g. x86_64.

I thing this change is orthogonal to what I am proposing here.

> 
> I also think that, when assuming presence of a syscall reduces the C 
> implementation of a socket function to just calling a single syscall 
> unconditionally, having one line for that function in a single 
> syscalls.list file is better than having a manually-maintained C 
> implementation.
> 

I do agree, and my proposal here in once we have a proper support
for direct syscall with bump minimal kernel support we can just
remove the C implementation and move it to syscalls.list without
the need to change and rework over various files.