Re: [PATCH RFC] Add support for linux memfd_create syscall

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 14 Jan 2015, Michael Kerrisk (man-pages) wrote:

> But, to take the larger point a little further. For system calls such
> as memfd_create(), presumably the most that that glibc is going to do
> is supply a wrapper and a header file with some declarations and
> constants. Does the glibc project then really want to get into the
> business of maintaining documentation for another project's APIs?

The first question is: does glibc want to get into the business of 
exporting interfaces for another project's APIs (and to what extent)?

What I suggested (and Carlos put at 
<https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers>) 
about adding syscall wrappers by default accords with historic practice, 
but there were objections at 
<https://sourceware.org/ml/libc-alpha/2014-10/msg00591.html>.  I don't 
believe we have reached consensus on when it should be considered useful 
to add an API of the form "call this Linux kernel syscall" (where the only 
glibc choices relate to such things as thread cancellation), as opposed to 
an OS-independent API (considered to be generally useful as part of the 
glibc API on all systems, even if any underlying kernel has chosen a 
different interface to similar functionality) that might initially be 
implemented only for systems using the Linux kernel.

(Given such consensus, it would then be very useful for someone to review 
Linux kernel syscalls - at least those that are architecture-independent - 
to identify cases that, according to such consensus, should have 
interfaces in glibc, and then to send patches implementing such 
interfaces.  Some syscalls already have bugs in Bugzilla requesting such 
interfaces: bug 6399 for gettid, bug 9712 for futex, bug 17252 for 
getrandom (a clear case for having an OS-independent interface, possibly 
in addition to a direct syscall interface), bug 17662 for renameat2.  But 
missing interfaces for one syscall does not of course block adding them 
for another, if that other syscall meets the relevant consensus.)

If an interface is exported, I think there must be a testcase - even if it 
does nothing useful on execution (and it may not be able to do anything 
useful on execution on old kernels, at least), it will at least make sure 
that calls to the function compile and link (we've had problems before 
with functions missing on some architectures).  See 
<https://sourceware.org/ml/libc-alpha/2013-07/msg00386.html> for a list of 
untested symbols (maybe a bit out of date, but I expect the vast bulk are 
still untested) - contributions of tests for existing untested symbols are 
welcome.

-- 
Joseph S. Myers
joseph@codesourcery.com