This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Principles for syscall wrappers, again
- From: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 26 May 2015 18:57:11 +0200
- 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> <20150526151000 dot GA17573 at brightrain dot aerifal dot cx>
On Tue, 2015-05-26 at 11:10 -0400, Rich Felker wrote:
> 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.
I can't see how offering a subset of the functionality provided by the
syscall is NIH'ing. We wouldn't offer additional stuff for obvious
reasons.
Do you really want to provide FUTEX_FD or FUTEX_REQUEUE?
> 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().
Nothing is breaking that, or is it?
Anyway, as Joseph requested, the specifics of the futex case need to be
discussed elsewhere. I just wanted to point out that we should make a
conscious decision about the (GNU) API that we offer and not just copy
stuff without further consideration.