This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Now, I disagree with the proposal for

* Because of thread cancellation (something that needs considering for 
each syscall wrapper, along with errno and the choice of types), 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 would be 
problematic, because glibc would need to install multiple versions of

* 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 and then add them to as well, accumulating compat duplicates in

But it's not clear there's consensus on adding syscall wrappers to, 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]