Add futex wrapper to glibc?

[Darren Hart]

On Sun, Oct 26, 2014 at 03:19:22AM -0400, Mike Frysinger wrote:
> On 23 Oct 2014 21:06, Joseph S. Myers wrote:
> > On Thu, 23 Oct 2014, Carlos O'Donell wrote:
> > > The largest problem right now is lack of documentation and that becomes
> > > lack of commitment from the kernel to maintain the API/ABI, and that
> > > translates into reluctance for glibc to create a wrapper.
> > 
> > That's not a plausible reason.  The presumption is that if any interface 
> > provided by the kernel could plausibly be used by userspace, it must stay 
> > stable.
> 
> sure, but Carlos is speaking in this specific case wrt futex, and it def suffers 
> from lack of documentation everywhere.  which provides quite a good amount of 
> wiggle room for the kernel peeps :).

This kernel peep, and I think I can speak for tglx as well, is not looking for
wiggle room here. We've provide Michael Kerrisk with the return values and error
conditions. I for one treat this as binding.

> 
> > * Otherwise, my inclination would be to default to adding wrappers (both 
> > for syscalls not used in glibc, and for cases such as futex where the 
> > syscall is used in glibc but can usefully be used directly as well) unless 
> > there is a clear reason not to.  This includes for architecture-specific 
> > syscalls.
> 
> i disagree here.  if the func is not going to be generally useful, i don't think 
> glibc should pick it up.  especially for arch-specific syscalls.  i think the 
> kernel itself is much better suited for providing a thin wrapper layer for 
> userspace as they're directly in control of the ABI (especially cross-arch) and 
> the API (via the UAPI headers), they can provide a full API for all syscalls 
> (unlike glibc per the caveats listed above), and it means there's a central 
> source point for everyone to use, not just glibc.
> 
> if the syscall is generally useful to people writing userland code, then i don't 
> see a problem with incorporating it in some fashion into the official GNU API.
> 

Agreed, and we have at least a couple examples of futex usage outside of glibc.

(futextest - OK, that one's self-serving, librcu, and I've heard of others)


-- 
Darren Hart
Intel Open Source Technology Center