This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Principles for syscall wrappers, again
- From: Rich Felker <dalias at libc dot org>
- To: libc-alpha at sourceware dot org
- Date: Tue, 26 May 2015 11:10:00 -0400
- Subject: Re: Principles for syscall wrappers, again
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1505182114090 dot 16300 at digraph dot polyomino dot org dot uk> <20150519000918 dot GB17573 at brightrain dot aerifal dot cx> <1432630525 dot 3077 dot 36 dot camel at triegel dot csb>
On Tue, May 26, 2015 at 10:55:25AM +0200, Torvald Riegel wrote:
> On Mon, 2015-05-18 at 20:09 -0400, Rich Felker wrote:
> > I would like to see futex in its own header, sys/futex.h, since it has
> > a number of macros. I also tend to think the function itself should be
> > variadic since a few of the argument slots have different types
> > depending on the command in use.
>
> Roland has argued that we should be adding GNU API extensions, not just
> Linuxisms. I think futex is a good example of that: I'd prefer us to
> expose functionality that is trimmed down to what's currently widely
> used (e.g., futex_wake(), futex_wait(), ... vs. a single variadic-arg
> futex()). That makes it easier for things like the Native Client to
> support it, and we can expose a refined interface to users (the futex
> syscalls has seen quite a few changes over time and not all of the
> initial functionality proved to be really useful).
>
> Thus, it seems to me we should explicitly discuss the GNU API we want to
> expose for each syscall's functionality that we want to offer, and not
> just expose syscalls interfaces as-is by default.
I think this is gratuitous NIH'ing and a disservice to applications.
Code which wants to use the futex API is already doing so via
syscall() with the existing API, and is most easily updated to use
futex(). Your proposed API is not any more general or easier to
provide on NaCl or elsewhere; the existing API can easily be provided
because it's equivalent.
Rich