Re: Principles for syscall wrappers, again

[Rich Felker <dalias at libc dot org>]

On Fri, May 29, 2015 at 10:37:33AM +0200, Torvald Riegel wrote:
> On Thu, 2015-05-28 at 16:51 +0000, Joseph Myers wrote:
> > On Tue, 26 May 2015, Rich Felker wrote:
> > 
> > > > 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.
> > 
> > Agreed.  As I said in 
> > <https://sourceware.org/ml/libc-alpha/2015-05/msg00764.html>, I think the 
> > API details to discuss are things such as the userspace types and the 
> > header with the declaration, not any more substantial rearrangement of the 
> > API - treating Linux as an API source like BSD and SysV, except for API 
> > details outside the scope of what the kernel defines.
> 
> Joseph, the fact that you comment on futex specifically tells me you're
> okay with discussing futex in detail in this thread (which I tried to
> avoid so far).
> 
> I suppose both you and Rich are thinking about this as the futex() API
> you want to expose:
> 
> int futex(int *uaddr, int op, int val, const struct timespec *timeout,
>                  int *uaddr2, int val3);

I would make it variadic with all but the first 3 optional; the types
for the rest are not consistent across commands.

> syscall() is multiplexing.  And so is futex().  Thus, by your logic,
> there's no need for offering futex() because syscall() is doing it
> already, just with *one part* of the multiplexing being variable.

No, the need to add futex is because it should be a cancellation
point, and syscall is not a cancellation point. If you want to write
custom sync primitives that interact with cancellation, futex must be
a cancellation point.

I'm not going to reply to the rest line-by-line, but I don't see how
futex() command multiplexing is any worse than fcntl(). Yes I agree
that, if this were being done fresh from day 1, a non-multiplexed API
is cleaner. That's not what my argument is about. What I believe here
is that:

1. As long as it doesn't have fundamental flaws(*), adopting an API
   with existing usage is better than trying to invent a new one to do
   the same thing.

2. There's a nontrivial risk of omitting access to some features in
   the proposed new non-multiplexed API, and then there's no way to
   get access to a cancellation-point futex command that has those
   features.

(*) By "fundamental flaws", I mean things that make the API unusable
for some purposes and that can't be worked around by wrapping, like
lack of thread-safety. If the existing API can be used to implement
your new API as wrappers, then the existing API does not have the kind
of "fundamental flaws" I'm talking about.

Rich