Specific Linux syscalls for glibc API

[Joseph Myers <joseph at codesourcery dot com>]

Following recent discussions of API sources for glibc, I propose that we 
consider the following Linux syscalls and related interfaces appropriate 
for the OS-independent GNU API, should someone post patches implementing 
them (possibly only for Linux), which would need to meet all the usual 
standards and would need to be reviewed in the usual way including 
especially for details such as errno and cancellation handling, the exact 
function prototypes, whether there are fallbacks for old kernels and what 
header has the declaration.  These functions may have OS-specific aspects, 
but I think are generically meaningful enough it's plausible they could be 
relevant on other OSes.


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

* futex and more specific futex_* interfaces for individual operations 
(bug 9712).


New functions (post-3.2 additions to the kernel):

* getrandom, plus BSD getentropy wrapper (bug 17252).

* renameat2 (bug 17662).

* sched_setattr.

* sched_getattr.

* memfd_create.

* execveat.

* membarrier.

* mlock2 (new for 4.4).


Wrappers are I think appropriate, but likely Linux-specific rather than 
part of the OS-independent GNU API (we have no consensus on where such 
wrappers should go, since there are both objections to having them in libc 
and objections to a separate libinux-syscalls.so.1 shared library):

* bpf (bug 18271).

* kcmp (or might consider for OS-independent API).

* seccomp.

* userfaultfd (or might consider to be in the next bullet point).

* This list excludes some extremely specialized new syscalls: 
finit_module, kexec_file_load.  Syscalls essentially for only one or two 
applications may be more controversial than syscalls that are inherently 
Linux-specific but of use to more general applications.


I make no proposal here regarding the bulk of older syscalls, but the list 
at <https://sourceware.org/ml/libc-alpha/2013-02/msg00030.html> may be of 
use to anyone considering their classification.  I also make no proposal 
regarding making some existing Linux-specific interfaces part of the 
OS-independent GNU API (so adding ENOSYS dummy versions for other systems, 
installing headers on all OSes, etc.), although likely some should be 
OS-independent interfaces.

-- 
Joseph S. Myers
joseph@codesourcery.com