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: Zack Weinberg <zackw at panix dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 27 Jun 2019 12:02:46 -0400
- Subject: Re: syscall wrappers policy (was re: glibc at the Toolchains microconference)
- References: <CAKCAbMggho7ToFYfUfYFg2RPMqcAQNFQpTJ0o+R+Pyh8=HWCWg@mail.gmail.com> <xno92jt4f1.fsf@greed.delorie.com>
On Thu, Jun 27, 2019 at 11:49 AM DJ Delorie <dj@redhat.com> wrote:
>
> 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).
I like this. "Minimal interface" is better than "doesn't do any
nontrivial work itself."
> > 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.
Yeah. I feel like there's a need, nowadays, for a language-agnostic
kernel API library and a dynamic loader completely decoupled from the
C library, but that's a big can of worms and we shouldn't let it get
in the way of anything else.
zw