Re: Add futex wrapper to glibc?

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

On Sun, 26 Oct 2014, Mike Frysinger wrote:

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

I don't think the kernel is well-suited for this; various issues around 
building objects for all the different ABIs, including ABI differences 
that are only relevant at the userspace level and not the kernel level, 
don't arise for kernel code (and only to a limited extent for vDSOs) - and 
then you get into things such as providing unwind / debug info for syscall 
stubs.  If the syscall is to be a cancellation point (and it was suggested 
the futex wrapper should be, for certain arguments) then the syscall 
implementation closely ties into libc internals (and if it sets errno, 
that means the object code for the implementation depends on libc, even if 
it would be possible to write C source code for it that does not).

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

Sometimes "access this Linux kernel interface" is generally useful (e.g. 
gettid, futex - and plenty of existing syscall wrappers).

> i think any syscall we think about adopting, this should be given 
> serious consideration.  ideally glibc's API should be stable across 
> platforms.  if the Linux syscall is so great as to warrant us adding a 
> wrapper, then it stands to reason that equivalent functionality should 
> be desirable on other platforms.  it doesn't mean we need to wait for 
> them to implement the kernel side, but we shouldn't be baking in pure 
> Linuxisms from the start. -mike

I don't think we actually need to decide at the time of adding a syscall 
wrapper whether it would be useful on other platforms - if we decide that 
later, we can always add the ENOSYS stub for Hurd use, or fallbacks for 
older Linux kernel versions, at that point.  (If we wish to use a function 
internally in glibc in OS-independent code, that would be a good 
indication that it should be made an OS-independent interface.)

Nor do I think we can reliably predict whether an interface is suitable to 
be OS-independent from whether it is generally useful with the Linux 
kernel - it may be necessary to see how several different OSes approach an 
issue before a good conclusion can be reached on what a portable 
OS-independent interface should look like.

-- 
Joseph S. Myers
joseph@codesourcery.com