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

  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(-)
  

* 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.)
  

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
  

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.
  

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
  

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.
  

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).
  

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.