Re: Principles for syscall wrappers, again

[Rich Felker <dalias at libc dot org>]

On Tue, May 26, 2015 at 06:57:11PM +0200, Torvald Riegel wrote:
> 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?

Linux does not provide FUTEX_FD, so no. I don't see why you wouldn't
want to support FUTEX_REQUEUE. The remarks about it having inherent
race conditions are wrong; they only apply to glibc's use of it. It's
perfectly valid to requeue a futex waiter to a lock as long as the
thread doing the requeue currently holds said lock, and in fact my
cond var implementation uses this (the lock being requeued to is an
internal lock, not the mutex).

> > 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?

No, but the NIH'd API would preclude a trivial mechanical change to
use the syscall wrappers.

> 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.

Plenty of stuff has been copied without further consideration even
recently -- the worst example is sendmmsg/recvmmsg which use the wrong
types. What I would like to see more than making minor but annoying
API differences in glibc vs Linux is some serious additional scrutiny
over the kernel folks when they add new interfaces without thinking
about problems they're going to make in userspace, so this stops
happening.

Rich