Re: support for calling Linux syscalls directly

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Jan 30, 2013 at 03:01:54PM -0800, H. Peter Anvin wrote:
> I have had a number of discussions with people on this topic,
> especially given that syscall(3) is fundamentally flawed on a number
> of architectures, and that some architectures have been forced to use
> nonstandard signatures, complicating things.
> 
> What I think makes sense is to create a library separate from glibc
> presumably called libinux containing the Linux-specific bits.  This
> libinux could ideally not just service glibc but also uClibc and
> Bionic (klibc itself is a little too "special" in that it doesn't have
> a dynamic linker at all.)

I'm not entirely against it, but I question the tradeoffs being
made...

1. Some of the syscalls missing from glibc, like gettid, are necessary
to use _existing_ interfaces in glibc -- things like sched_*() which
take tids despite being wrongly documented as taking pids, as well as
some fcntl and timer interfaces. As much as I hate the idea of
exposing tids to applications, if the functions that need tid
arguments are in libc, I think gettid (and maybe pthread_gettid_np?)
should be too.

2. Library creep is bad. We live in an age where "ldd" outputting 30+
lines for trivial command line tools and hundreds of lines for large
gui applications is the norm. Is it really worth adding a new shared
library (load time and an extra 4k+ of wasted ram per process using
it) for what's going to end up being (at most) a few kb of code? Pure
syscall wrappers are tiny.

3. On the issue of difficulty making the syscall() directly -- things
like argument order, 64-bit argument padding on 32-bit archs, etc. --
I don't think any of the syscalls we're talking about are affected by
these issues. Please correct me if I'm wrong. If I'm right, then it's
not really all that important to provide wrappers at all; the 1 or 2
applications that use these syscalls can just use syscall()
themselves.

What I'd like to see is an honest reevaluation of the currently
missing syscall wrappers glibc doesn't provide. If there are some that
libc should provide, let's get them added. If they're really not meant
to be used except in a single application (or not at all -- deprecated
junk) then they can just be left alone.

Rich