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

[DJ Delorie]

Zack Weinberg <zackw@panix.com> writes:
> First, I think we need a definition of “syscall wrapper.”  Proposed:

I offer alternate wording, not because I think mine is better, but to
stir the pot a bit and get people thinking :-)

"A syscall wrapper is a function whose primary (preferably sole) purpose
is to provide a minimal C-callable interface to a kernel function."

I think that explains why glibc has them (C-callable), limits its scope
(primary/sole purpose) and defines its purpose (kernel function).

How glibc implements them, and how much it needs to do to retain
compatiblity with other C APIs and standards, can be documented
separately.  Or we could add ", consistent with other glibc functions"
to the end of the above.

> Second, I think we need to talk a bit about the rationale for the
> policy.

I think definining it as a "C API" makes it clear that the C library is
the right place for C functions.  That also keeps us from trying to be
the ONLY kernel API library, when other languages need non-C wrappers.