syscall wrappers policy (was re: glibc at the Toolchains microconference)

[Zack Weinberg <zackw at panix dot com>]

[sorry about the blank reply earlier, I pushed the wrong button]

On Wed, Jun 26, 2019 at 5:04 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> Could you please review the language here:
> https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers
>
> I drafted it in 2014-10-23 based on comments from Joseph Myers and the
> community (almost 5 years ago!)

This seems mostly right to me, but I have some concerns.

First, I think we need a definition of “syscall wrapper.”  Proposed: A
syscall wrapper is a function that, on a system with a traditional
Unix-style kernel (i.e. we don’t look at Hurd when assessing this)
does substantially all of its work by calling into the kernel.  It may
shuffle its arguments around, it may translate between the glibc ABI
and some lower-level ABI, and it may not actually perform a
system-call trap (e.g. `clock_gettime`), but it couldn’t do what it
does without invoking kernel code, and it doesn’t do any nontrivial
work itself.

The “nontrivial work itself” part is meant to draw a line with `open`
and `signal` on the “is a syscall wrapper” side (even though, on
modern systems, the “true” system calls they use are named `openat`
and `rt_sigaction` respectively), and `pthread_mutex_lock` on the
“isn’t a syscall wrapper” side (even though it does make system calls
under some circumstances, it does a lot of work itself).  I would like
to tighten this up but I’m not having any luck thinking of a better way
to phrase it.

Second, I think we need to talk a bit about the rationale for the
policy.  Something about how it has traditionally been the C library’s
responsibility to provide minimally mediated access to all of the
functionality of the kernel, and how in the past GNU libc has
hesitated to add Linux-specific syscall wrappers on portability and/or
backward compatibility grounds, but we now think that was a mistake.

> * If a syscall is obsoleted by another syscall (or otherwise
>   considered obsolete), there is no need to add a wrapper to glibc.

In the user-facing documentation (not necessarily the consensus rules)
it might be worth adding some kind of reassurance that we’re not going
to get rid of `open` even though it _is_ traditionally a “syscall
wrapper” and `openat` supersedes it.  “Existing functions that
traditionally were syscall wrappers will be preserved, even if the
syscall that does exactly what they do is obsoleted by a newer one
with broader capabilities, if they are specified by ISO C and/or
POSIX, or if they are widely used” or something like that.

But, at the same time, we _do_ need to say that syscall wrappers that
are OS-specific are subject to weaker compatibility guarantees.  We
have, after all, been removing things like nfsservctl and ustat.

> * If a syscall cannot meaningfully be used behind glibc's back, or
>   is not useful in the glibc context except for in the ways in which
>   it is used by glibc

I would prefer to narrow this to something like what I said in my
previous message: “glibc will not provide wrappers for syscalls that
are _impossible_ to use from a program linked against glibc without
corrupting glibc’s internal data structures.  For instance,
`set_thread_area`, `set_tid_address`, `set_robust_list`.”
“Meaningfully used” and “not useful in the glibc context” are too
fuzzy and I’m worried we will be setting ourselves up for arguments.

> * If there's a glibc function that's not quite a direct wrapper of
>   the syscall but provides all the functionality of it that can
>   usefully be used in a program using glibc, there is no need
…
> * Wrappers should be added … unless there is a clear reason not to

I do not understand the rationale for these exceptions.  Did you have
specific cases in mind when you wrote these?

(I’m particularly concerned that the “not quite a direct wrapper” rule
would be used to argue against exposing a variant of `clone` that
returns twice like `fork` does, which is a thing I think we should
have.  You probably _can_ do any fork-with-options operation with the
`clone` wrapper we have, but having to separate the child-side code to
its own function and allocate stack space for it can be a serious obstacle.)

zw