Re: Principles for syscall wrappers, again

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 22 May 2015, Roland McGrath wrote:

> I think I've been the most strident skeptic about adding Linuxisms to
> libc, so if we manage to get me to stop complaining then we are
> probably in a pretty good place.
> 
> To me there is only one category where things are clear.  That's when
> there is consensus that a new function is worthwhile to have as part
> of the OS-independent GNU API.  In that case we aren't talking about
> adding a wrapper for a Linux syscall.  We're talking about adding a
> new GNU API, and it might happen to be that the sysdeps implementation
> of that for Linux is nothing more than a syscall wrapper.

I think it's appropriate for the additions of APIs taken from Linux 
syscalls to be roughly consistent with historical practice for when APIs 
go in glibc.

To me, that suggests that if we don't add such APIs as Linux-specific 
APIs, we should instead treat Linux like BSD and SysV were historically 
treated as sources of APIs, as described in "Berkeley Unix, SVID, POSIX, 
Standards and Portability" in intro.texi.  So if a Linux syscall API seems 
useful for non-Linux-specific applications, the starting point would be 
that it is appropriate for the GNU API - and while we'd need to consider 
issues such as the header for the declaration, the userspace types to use, 
whether it is a cancellation point, and whether it sets errno or uses some 
other error return convention, we should not generally get into 
second-guessing the API design and reworking the whole design of an API 
which has already passed the review process for Linux kernel/userspace 
APIs on linux-api.  (That review process is a lot more thorough than it 
used to be; there have been past cases before where glibc's version of an 
API added a flags argument where the original syscall lacked one, and I 
think it less likely now that a new syscall would be added without such 
extensibility.)

It would then be possible for such APIs to move from a syscalls.list entry 
to a more complicated fallback providing compatibility for older kernels, 
if desired in a particular case, and possible for other OS ports of glibc 
to add implementations if they desire (otherwise the ENOSYS version would 
be used - just as several functions from other OSes exist in glibc with 
the default ENOSYS implementations used under the Linux kernel).

Thus, I'd suggest that if we don't want new Linux-specific APIs in libc, 
we should set standards that would consider all of futex gettid getrandom 
renameat2 sched_setattr sched_getattr memfd_create execveat appropriate 
for the OS-independent GNU API (and I don't know about bpf kcmp seccomp).

> My second concern is adding cruft to the core libc APIs.  That means
> what you can see in header files that are installed in all OS
> configurations, and what you can link to without special options
> beyond -lc, -lpthread (or -pthread), -lrt, -ldl, -lm, or -lutil.  I'm
> more concerned about the header files than the link-time availability.
> 
> I propose that we rule out adding any declarations to core libc API
> header files that are not entering the OS-independent GNU API.

It's already the case that Linux-specific APIs are declared in sys/ 
headers that are only installed from sysdeps/unix/sysv/linux/Makefile (or 
in a few cases, in Linux-specific versions of bits/ headers included from 
more generic headers).

> We could provide OS-specific ABIs in an OS-specific shared library,
> e.g. libinux-syscalls.so.N.  This library's SONAME could change
> without any changes to core libc ABIs.  (We would change the SONAME
> when we want to completely drop some obsolete syscalls.)  If this
> library contains nothing but syscall wrappers or equivalently trivial
> code (importantly, stateless code that doesn't need any data objects
> of permanent extent), then it won't be a practical problem to have
> multiple versions of the library loaded in the same process at the
> same time--so all the usual issues that make changing SONAMEs very
> hard don't really apply.

I'd be wary of assuming that (for example) a syscall wrapper with 
cancellation from an old glibc version will work with libc.so from a new 
glibc version that handles cancellation differently, so if you changed 
SONAME that would suggest building all the versions with different SONAMEs 
as part of the same glibc build (which seems like an undue complication).  
So changing the SONAME of such a library seems dangerous to me.

I'd think of such a library as only being for syscalls that fail my 
suggested criteria for being too Linux-specific (or maybe for being 
architecture-specific) - not for anything that could plausibly be useful 
on another OS, or where a fallback implementation for older kernels might 
make sense.

-- 
Joseph S. Myers
joseph@codesourcery.com