This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]