Patchwork sparc64: remove bind, listen and setsockopt from syscalls.list

login
register
mail settings
Submitter Aurelien Jarno
Date March 1, 2016, 3:17 p.m.
Message ID <1456845449-1871-1-git-send-email-aurelien@aurel32.net>
Download mbox | patch
Permalink /patch/11154/
State New
Headers show

Comments

Aurelien Jarno - March 1, 2016, 3:17 p.m.
The bind, listen and setsockopt syscalls have recently been added in
kernel 4.4. They should therefore not appear in syscalls.list as it
means they are use inconditionally instead of possibly using the
the socketcall fallback.

All other syscalls from syscalls.list with an equivalent socketcall
version are available in kernel 3.2, which is the required minimum.

Changelog:
	* sysdeps/unix/sysv/linux/sparc/sparc64/syscalls.list (bind, listen,
	setsockopt): Remove.
---
 ChangeLog                                           | 5 +++++
 sysdeps/unix/sysv/linux/sparc/sparc64/syscalls.list | 3 ---
 2 files changed, 5 insertions(+), 3 deletions(-)
Florian Weimer - March 1, 2016, 4:06 p.m.
* Aurelien Jarno:

> The bind, listen and setsockopt syscalls have recently been added in
> kernel 4.4. They should therefore not appear in syscalls.list as it
> means they are use inconditionally instead of possibly using the
> the socketcall fallback.

Right.

> All other syscalls from syscalls.list with an equivalent socketcall
> version are available in kernel 3.2, which is the required minimum.

Doesn't this still cause unnecessary code duplication because there
are now two implementations, one in generic code and one generated for
sparc64?  (I'm not familiar with the way the sysdeps mechanism works.)
Aurelien Jarno - March 1, 2016, 5:08 p.m.
On 2016-03-01 17:06, Florian Weimer wrote:
> * Aurelien Jarno:
> 
> > The bind, listen and setsockopt syscalls have recently been added in
> > kernel 4.4. They should therefore not appear in syscalls.list as it
> > means they are use inconditionally instead of possibly using the
> > the socketcall fallback.
> 
> Right.
> 
> > All other syscalls from syscalls.list with an equivalent socketcall
> > version are available in kernel 3.2, which is the required minimum.
> 
> Doesn't this still cause unnecessary code duplication because there
> are now two implementations, one in generic code and one generated for
> sparc64?  (I'm not familiar with the way the sysdeps mechanism works.)

That causes source code duplication, but the binary code will only
contain the code generated from syscalls.list. I actually guess that for
syscalls that are available on all Linux architectures (I don't know if
it is the case after raising the minimum version to 3.2), we can remove
the generic implementation and add an entry to
sysdeps/unix/sysv/linux/syscalls.list.

Aurelien
Adhemerval Zanella Netto - March 1, 2016, 6:06 p.m.
On 01-03-2016 14:08, Aurelien Jarno wrote:
> On 2016-03-01 17:06, Florian Weimer wrote:
>> * Aurelien Jarno:
>>
>>> The bind, listen and setsockopt syscalls have recently been added in
>>> kernel 4.4. They should therefore not appear in syscalls.list as it
>>> means they are use inconditionally instead of possibly using the
>>> the socketcall fallback.
>>
>> Right.
>>
>>> All other syscalls from syscalls.list with an equivalent socketcall
>>> version are available in kernel 3.2, which is the required minimum.
>>
>> Doesn't this still cause unnecessary code duplication because there
>> are now two implementations, one in generic code and one generated for
>> sparc64?  (I'm not familiar with the way the sysdeps mechanism works.)
> 
> That causes source code duplication, but the binary code will only
> contain the code generated from syscalls.list. I actually guess that for
> syscalls that are available on all Linux architectures (I don't know if
> it is the case after raising the minimum version to 3.2), we can remove
> the generic implementation and add an entry to
> sysdeps/unix/sysv/linux/syscalls.list.
> 
> Aurelien
> 

This patch lgtm since sparc64 is already using the default linux
implementation for these syscalls.

Regarding the code duplication and syscalls.list I would advise to include
only the non-cancellable syscalls on the syscall.list since I am currently
working on reramp the cancellation code.
Mike Frysinger - March 1, 2016, 7:58 p.m.
On 01 Mar 2016 16:17, Aurelien Jarno wrote:
> The bind, listen and setsockopt syscalls have recently been added in
> kernel 4.4. They should therefore not appear in syscalls.list as it
> means they are use inconditionally instead of possibly using the
> the socketcall fallback.
> 
> All other syscalls from syscalls.list with an equivalent socketcall
> version are available in kernel 3.2, which is the required minimum.

should this be posted to older branches too ?
-mike
Aurelien Jarno - March 1, 2016, 8:46 p.m.
On 2016-03-01 14:58, Mike Frysinger wrote:
> On 01 Mar 2016 16:17, Aurelien Jarno wrote:
> > The bind, listen and setsockopt syscalls have recently been added in
> > kernel 4.4. They should therefore not appear in syscalls.list as it
> > means they are use inconditionally instead of possibly using the
> > the socketcall fallback.
> > 
> > All other syscalls from syscalls.list with an equivalent socketcall
> > version are available in kernel 3.2, which is the required minimum.
> 
> should this be posted to older branches too ?

Yes, other branches are affected as soon as kernel headers version 4.4+
are used to build the GNU libc. I plan to backport the patch once it has
been accepted in master.
Joseph Myers - March 2, 2016, 3:05 a.m.
On Tue, 1 Mar 2016, Aurelien Jarno wrote:

> The bind, listen and setsockopt syscalls have recently been added in
> kernel 4.4. They should therefore not appear in syscalls.list as it
> means they are use inconditionally instead of possibly using the
> the socketcall fallback.

Any new socket syscalls not in syscalls.list should also have the 
appropriate __ASSUME_* macros defined in kernel-features.h (although that 
change wouldn't be appropriate for backporting).
Aurelien Jarno - March 2, 2016, 7:49 a.m.
On 2016-03-02 03:05, Joseph Myers wrote:
> On Tue, 1 Mar 2016, Aurelien Jarno wrote:
> 
> > The bind, listen and setsockopt syscalls have recently been added in
> > kernel 4.4. They should therefore not appear in syscalls.list as it
> > means they are use inconditionally instead of possibly using the
> > the socketcall fallback.
> 
> Any new socket syscalls not in syscalls.list should also have the 
> appropriate __ASSUME_* macros defined in kernel-features.h (although that 
> change wouldn't be appropriate for backporting).

Indeed you are correct. I'll send it as an additional patch to ease
backporting.

Patch

diff --git a/ChangeLog b/ChangeLog
index 9dabeca..fb14699 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@ 
+2016-03-01  Aurelien Jarno  <aurelien@aurel32.net>
+
+	* sysdeps/unix/sysv/linux/sparc/sparc64/syscalls.list (bind, listen,
+	setsockopt): Remove.
+
 2016-02-26  Joseph Myers  <joseph@codesourcery.com>
 
 	* sysdeps/unix/sysv/linux/alpha/kernel-features.h
diff --git a/sysdeps/unix/sysv/linux/sparc/sparc64/syscalls.list b/sysdeps/unix/sysv/linux/sparc/sparc64/syscalls.list
index 3d1c1da..cf18eb4 100644
--- a/sysdeps/unix/sysv/linux/sparc/sparc64/syscalls.list
+++ b/sysdeps/unix/sysv/linux/sparc/sparc64/syscalls.list
@@ -3,18 +3,15 @@ 
 # Override select.S in parent directory:
 select		-	select		C:5	__select	select
 accept		-	accept		C:3	__libc_accept	__accept accept
-bind		-	bind		3	__bind		bind
 connect		-	connect		C:3	__libc_connect	__connect connect
 getpeername	-	getpeername	3	__getpeername	getpeername
 getsockname	-	getsockname	3	__getsockname	getsockname
 getsockopt	-	getsockopt	5	__getsockopt	getsockopt
-listen		-	listen		2	__listen	listen
 recv		-	recv		C:4	__libc_recv	__recv recv
 recvfrom	-	recvfrom	C:6	__libc_recvfrom	__recvfrom recvfrom
 recvmsg		-	recvmsg		C:3	__libc_recvmsg	__recvmsg recvmsg
 send		-	send		C:4	__libc_send	__send send
 sendmsg		-	sendmsg		C:3	__libc_sendmsg	__sendmsg sendmsg
 sendto		-	sendto		C:6	__libc_sendto	__sendto sendto
-setsockopt	-	setsockopt	5	__setsockopt	setsockopt
 shutdown	-	shutdown	2	__shutdown	shutdown
 socketpair	-	socketpair	4	__socketpair	socketpair