Re: Principles for syscall wrappers, again

[Roland McGrath <roland at hack dot frob dot com>]

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.

My top concern is adding cruft to the core libc ABIs.  That means
specifically symbols in the shared objects for libc, libpthread,
librt, libdl, libm, and libutil.

I propose that we rule out adding any symbols to the core libc ABIs
that are not entering the OS-independent GNU API.

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.

If we follow those rules, then I'm not very concerned about the other
details.  I'll elaborate.

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.

My preference would be that we not put such OS-specific ABIs into the
common link-time API either.  That is, programs would be required to
link explicitly with -linux-syscalls.  But I will not stand in the way
of a contrary consensus, which presumably would be implemented by
adding 'AS_NEEDED ( libinux-syscalls.so.N )' into the libc.so linker
script.

In this context, the principles Joseph described seem fine enough to
me.  They might even be more conservative than we need to be.


Thanks,
Roland