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: Aurelien Jarno <aurelien at aurel32 dot net>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, Stefan Liebler <stli at linux dot vnet dot ibm dot com>
- Date: Thu, 31 Dec 2015 22:13:53 +0100
- 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> <alpine dot DEB dot 2 dot 10 dot 1512311816490 dot 15940 at digraph dot polyomino dot org dot uk>
On 2015-12-31 18: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?
I personally haven't checked. I have seen that compiling glibc against
4.3 kernel headers produced this wrong code. I then looked on master and
then realized these syscalls have been removed from syscalls.list. I
haven't really investigating more given I though the problem was
understood.
All that said we don't want these syscalls to be used as soon as we use
recent enough kernel headers as the resulting libc might be then used on
an older kernel.
> 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.
Ok, I'll try to investigate in the next days.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net