Re: Add futex wrapper to glibc?

[Mike Frysinger <vapier at gentoo dot org>]

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

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

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

absolutely

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

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

Attachment: signature.asc
Description: Digital signature