This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: syscall wrappers policy (was re: glibc at the Toolchains microconference)
- From: DJ Delorie <dj at redhat dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: carlos at redhat dot com, libc-alpha at sourceware dot org
- Date: Thu, 27 Jun 2019 11:48:50 -0400
- Subject: Re: syscall wrappers policy (was re: glibc at the Toolchains microconference)
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.