Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 10 Jun 2016, Carlos O'Donell wrote:

> > For gettid I think the actual issue is difficulty in establishing 
> > consensus in the absence of unanimity.  That's caused issues for all of: 
> > gettid / pthread_gettid_np, explicit_bzero, strlcpy / strlcat, Linux 
> > syscall wrappers in general especially where not appropriate for the 
> > OS-independent GNU API.  (I think all of those are appropriate for 
> > inclusion in glibc.)
>  
> The OS-independent GNU API is in my mind an issue of documentation,
> describing which APIs are Linux-specific and which are not.

There were objections from Roland and Mike at least to adding 
Linux-specific APIs to libc.so.

Now, I disagree with the proposal for libinux-syscalls.so:

* Because of thread cancellation (something that needs considering for 
each syscall wrapper, along with errno and the choice of types), 
libinux-syscalls.so would be closely tied to a particular libc version, so 
you can't readily keep around copies from multiple libc versions.

* Thus, removing any interfaces from it to add them to libc.so would be 
problematic, because glibc would need to install multiple versions of 
libinux-syscalls.so.

* We cannot readily tell when adding an interface whether it would remain 
Linux-specific or be adopted by other OSes in future, and so whether it 
belongs in the OS-independent GNU API or not.  So we cannot tell when 
adding an interface which library it belongs in.  So we'd be likely 
repeatedly to add interfaces to libinux-syscalls.so and then add them to 
libc.so as well, accumulating compat duplicates in libinux-syscalls.so.

But it's not clear there's consensus on adding syscall wrappers to 
libc.so, and there certainly isn't unanimity.

> I would be happy to see gettid implemented as a wrapper if someone
> would step up to document exactly how it behaves and where it is valid
> to use the resulting return value and in what APIs. That I think is
> where everyone balks at the work.

I think the answer is that the return value may be used with syscalls that 
take tids (which are legimitate interfaces for glibc users to use, in most 
cases), some of which may have matching glibc interfaces and some of which 
may not.  While we should describe what wrappers do in the glibc manual, 
ultimately for Linux-specific syscall wrappers the kernel's behavior is 
more authoritative than the manual.

-- 
Joseph S. Myers
joseph@codesourcery.com