Re: Add futex wrapper to glibc?

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 23 Oct 2014, Carlos O'Donell wrote:

> > I would really like to expose futex(2) as a public interface and see
> > it documented there.. :-) I know that's something of a separate topic,
> > but it seems like a good time to discuss since the documentation is
> > going to be worked on, and since C11 atomics make having futex()
> > available to applications A LOT more desirable.
> 
> We've had this discussion before, but I can't find the reference in
> the libc-alpha archives.

See bug 9712 (and comment 4 therein where I pointed to past discussions of 
the general question of which syscall wrappers to add).

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

We need to reach consensus on when to add syscall wrappers to glibc (and I 
suppose on how to determine whether a given syscall wrapper should be a 
cancellation point).  Possible considerations include:

* If a syscall is obsoleted by another syscall (or otherwise considered 
obsolete), there is no need to add a wrapper to glibc.

* If a syscall cannot meaningfully be used behind glibc's back, or is not 
useful in the glibc context except for in the ways in which it is used by 
glibc, but can only be used directly by glibc, there is no need to add a 
wrapper to glibc (this probably applies to set_thread_area, for example).

* If there's a glibc function that's not quite a direct wrapper of the 
syscall but provides all the functionality of it that can usefully be used 
in a program using glibc, there is no need to add a wrapper to glibc.

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

* If a wrapper is provided, there should also be a header with 
corresponding declarations (that either provides any relevant constants / 
structures or includes appropriate kernel neaders providing them).

* There may be cases where a function is meaningful not just with Linux 
kernels supporting the syscall, and should be provided with some kind of 
fallback for older kernels, and possibly made part of the glibc API for 
systems with other kernels as well.

* If we do get consensus on principles, we still need someone to go 
through current syscall lists and work out a more detailed proposal for 
which syscalls to add to glibc, then actually add them once there is 
consensus on those sets.

> We are IMO at the stage where futex is stable, few things are changing,
> and with documentation in place, I would consider adding a futex wrapper.
> However, per other discussions on errors, I'd actually add a non-trivial
> C wrapper to enforce that the kernel does not return error codes that
> are unexpected.

I don't think that makes sense for futex.  I think such checks only make 
sense where glibc is making use of futex within its own code - there it 
may sometimes be useful to sanity-check results match glibc's 
expectations.  I also think it's desirable for any such syscall wrapper to 
be usable with futex operations that may be added to the kernel in future 
(i.e. someone should only need new kernel headers to build code using new 
operations, not a new glibc binary that knows how to check things for 
those new operations).

-- 
Joseph S. Myers
joseph@codesourcery.com