Re: Principles for syscall wrappers, again

[Torvald Riegel <triegel at redhat dot com>]

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.