This is the mail archive of the
mailing list for the glibc project.
Re: Principles for syscall wrappers, again
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Thu, 28 May 2015 15:51:22 +0000
- Subject: Re: Principles for syscall wrappers, again
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1505182114090 dot 16300 at digraph dot polyomino dot org dot uk> <20150522235242 dot 50BF82C3ABD at topped-with-meat 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
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
Joseph S. Myers