This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH-for-2.21-and-2.22] s390-64: remove socketcall syscalls
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Aurelien Jarno <aurelien at aurel32 dot net>
- Cc: <libc-alpha at sourceware dot org>, Stefan Liebler <stli at linux dot vnet dot ibm dot com>
- Date: Thu, 31 Dec 2015 18:21:15 +0000
- Subject: Re: [PATCH-for-2.21-and-2.22] s390-64: remove socketcall syscalls
- Authentication-results: sourceware.org; auth=none
- References: <1451010098-22120-1-git-send-email-aurelien at aurel32 dot net>
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