[PATCH-for-2.21-and-2.22] s390-64: remove socketcall syscalls

[Adhemerval Zanella]

On 31-12-2015 16:21, Joseph Myers wrote:
> On Fri, 25 Dec 2015, Aurelien Jarno wrote:
> 
>> From: Stefan Liebler <stli@linux.vnet.ibm.com>
>>
>> Remove socketcalls in syscalls.list for s390-64. They were never used
>> on s390x and produce wrong code when glibc is built against 4.3 kernel
>> headers.
> 
> Could you explain why they produce wrong code?
> 
> Long term, once we can assume a kernel with direct socket syscalls on all 
> architectures, we should get rid of socketcall support.  And the preferred 
> form of getting rid of it isn't to have lots of C files calling syscall 
> macros.  It's to use syscalls.list entries where possible, with C files 
> only if needed because e.g. a function doesn't correspond directly to a 
> syscall (Adhemerval's cancellation changes would add "syscall is a 
> cancellation point" to the cases needing C files; I'm unconvinced that 
> reducing the number of cases that can use syscalls.list is a good idea).  
> And those syscalls.list entries would where possible be those in 
> sysdeps/unix/syscalls.list (appropriately adjusted to be in sync with the 
> current Linux-specific entries as needed).
> 
> So, if there are cases where listing such a syscall in syscalls.list 
> produces wrong code, we need to understand those cases properly so we can 
> allow for them in the future when eliminating socketcall support and using 
> syscalls.list entries in more cases, architecture-independent.
> 

Regarding my recent patches for cancellation changes, I am indifferent if
the syscall implementation is done either by direct C-code or through
syscalls.list auto-generation.  However, current syscall implementation
in GLIBC is cumbersome: it requires three definition for the exactly
same thing (assembly definitions for the syscalls.list, another
assembly definition that does the cancellation hackery and C macros for
inline syscalls), whic adds unnecessary complexity and maintenance.

My view it was required back in time when compiler generated code for the
C inline calls was deficient (either by missing some argument constraints
like i386/arm or by due some performance issues), however currently I 
see we should aim for only one definition: through C-code generated
syscalls (either by auto-generation from the syscalls.list or independent
C files).

So my idea is to first remove all the sysdep-cancel.h assembly hackery
to all ports, so a new port will only require to provide the assembly
macro definition and the C counterpart.  It should provide a clean
way for the new cancellation code and make the missing ports adjustment
simpler.

We can later change the syscalls.list generation to spill C code using
the INLINE_xxx macros.  It adds some complexity regarding the headers
inclusion, but it simplifier even further the requiring platform specific
code required for a new port and allows some cleanup on current ones.
We can even add the cancellation entrypoints in the syscalls.list by
using the SYSCALL_CANCEL macro as well.