This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 2/2] Use direct socket syscalls for new kernels on sparc
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Aurelien Jarno <aurelien at aurel32 dot net>
- Cc: <libc-alpha at sourceware dot org>, "David S . Miller" <davem at davemloft dot net>
- Date: Thu, 3 Mar 2016 22:42:35 +0000
- Subject: Re: [PATCH v2 2/2] Use direct socket syscalls for new kernels on sparc
- Authentication-results: sourceware.org; auth=none
- References: <1456907123-6199-1-git-send-email-aurelien at aurel32 dot net> <1456907123-6199-3-git-send-email-aurelien at aurel32 dot net> <alpine dot DEB dot 2 dot 10 dot 1603021449060 dot 12014 at digraph dot polyomino dot org dot uk> <20160303075840 dot GA28642 at aurel32 dot net>
On Thu, 3 Mar 2016, Aurelien Jarno wrote:
> On 2016-03-02 14:52, Joseph Myers wrote:
> > On Wed, 2 Mar 2016, Aurelien Jarno wrote:
> >
> > > Direct socket syscalls have been added in kernel 4.4 on sparc for
> > > bind, listen and setsockopt. Other direct socket syscalls were present
> > > before kernel 3.2 and are listed directly in syscalls.list, so there is
> > > no need to add them there.
> >
> > Listed directly in syscalls.list for sparc64. Don't they need __ASSUME_*
> > adding for sparc32?
>
> Yes, I think they need that. I looked at the exact list, and it seems
> that the send syscall is not provided on sparc. Does it means we should
> also define __ASSUME_SENDTO_FOR_SEND_SYSCALL and remove it from
> syscalls.list?
If the non-socketcall way of implementing a socket function on a given
architecture involves use of a different syscall, then the appropriate one
of __ASSUME_ACCEPT4_FOR_ACCEPT_SYSCALL, __ASSUME_SENDTO_FOR_SEND_SYSCALL,
__ASSUME_RECVFROM_FOR_RECV_SYSCALL should be defined under the relevant
conditions for the syscall in question to be available (and there should
not be a syscalls.list entry for the syscall that does not exist). I have
not reviewed exactly what is right for sparc32 and sparc64 in this regard.
>
--
Joseph S. Myers
joseph@codesourcery.com