Re: Specific Linux syscalls for glibc API

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 18 Nov 2015, Florian Weimer wrote:

> On 11/17/2015 05:34 PM, Joseph Myers wrote:
> 
> > Old functions (where any relevant syscalls have been in the kernel since 
> > 3.2 or earlier, when routine addition of syscall wrappers to glibc 
> > stopped):
> > 
> > * gettid, pthread_gettid_np (bug 6399).
> 
> I have no problem with adding those for Linux only.  I have some
> concerns about exposing them as a general (OS-independent) interface
> because they NPTL deals with TIDs appears quite broken.  On the other
> hand, it looks like a better implementation would support all uses cases
> currently supported by NPTL in a race-free manner, and some other useful
> scenarios as well.

Do you then think that the TID concept is unique to Linux - that it 
doesn't exist for any other NPTL ports, such as that for NaCl or the 
variant used in the out-of-tree kFreeBSD port of glibc, or on other OSes?

(If we drop the libinux-syscalls.so.1 idea and accept Linux-specific 
interfaces in libc.so.N, I don't object to erring on the side of treating 
more interfaces as Linux-specific in the first instance with generic stubs 
potentially being added later.)

> > * getrandom, plus BSD getentropy wrapper (bug 17252).
> 
> A high-quality implementation of getrandom is difficult because the most
> interesting property of getrandom is that it cannot fail in some modes
> of operation.  A wrapper would have to provide reliable emulation,

That's not our problem to solve.  The manpage explicitly says that the 
return value must be checked.  We should provide a wrapper, not 
necessarily with any emulation, and if there's emulation, it might fail.  
At some future point glibc will require a kernel version recent enough to 
have the syscall, at which point applications using new enough glibc may 
know, on Linux but not necessarily on other OSes, that it cannot fail.  We 
should not delay adding a wrapper until we can rely on the syscall being 
available.

> otherwise application code would need to check for ENOSYS, entirely
> defeating the purpose of this interface.

Applications supporting older kernels need to allow for the syscall / 
function not being available anyway.  Again, not our problem to solve when 
providing a wrapper.

> > * renameat2 (bug 17662).
> 
> I'm okay with that as long as we do not try to provide emulation (so,
> return ENOSYS on an older kernel and EINVAL without file system
> support).  This system call is rather Linux-specific, though.

I don't see it as Linux-specific.  That is, it seems to be defined in a 
generic way that it's entirely plausible other OSes would be able to 
implement, whether in the kernel or (e.g. on Hurd) in userspace to a 
greater or lesser extent.

My concept of OS-independent APIs is intended to be such that the older 
BSD and SVID APIs are not considered OS-specific simply if in fact they 
were only natively implemented for particular BSD or SysV systems, but the 
concept of the API is meaningful for other OSes and it's plausible at 
least some features could be supported on other OSes if someone so 
desires.

> > * sched_setattr.
> > 
> > * sched_getattr.
> 
> I think we need to discuss to what extent emulation is possible, but

I don't think that's a necessary part of adding a syscall wrapper.  If an 
interface is OK, it should always be OK to add a wrapper that doesn't try 
emulation on older kernels, with emulation being an incremental 
improvement if someone is interested in it.

> otherwise, these seem reasonable to add, but they are Linux-specific,
> not for the general OS-independent API.

Under my model of what counts as OS-independent (with, as noted, the 
caveat that we could treat more as Linux-specific if it doesn't mean 
putting them in a separate library), I don't see these are more 
Linux-specific than the concept of TIDs.

> > * execveat.
> 
> Reasonable to add.  Can be emulated faithfully with /proc/self/fd and
> O_PATH.  Not sure if this is for the OS-independent API, but the other
> *at are OS-independent, so it makes sense to put it there as well.

This is the one that's most completely obviously OS-independent even for 
a narrow concept of OS-independence.  It's also of use for implementing 
fexecve when available.

-- 
Joseph S. Myers
joseph@codesourcery.com