Re: Principles for syscall wrappers, again

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2015-05-29 at 11:19 +0000, Joseph Myers wrote:
> On Fri, 29 May 2015, Torvald Riegel wrote:
> 
> > 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.
> 
> The syscall function doesn't deal with cancellation.

Agreed.  But not all futex operations are cancellation points either.

And what if we had syscall() and a variant of that that supports
cancellation?  Then the cancellation argument you make is taken care of,
or am I missing something?

> My proposed principles are non-exclusive.  I consider the futex call to be 
> useful in the same way as open or ptrace or ioctl - a function providing 
> access to a range of related operations, some system-independent and some 
> with system-specific aspects.  This does not exclude the possibility of 
> other APIs being useful for particular cases of the futex call, or indeed 
> of applying my proposed principles recursively to cases of particular 
> multiplexing system calls.
> 
> A futex function is useful to provide access to new futex operations 
> without needing libc changes for them, much like open and ptrace provide 
> access to new operations.

I would not be opposed to *additionally* offering a futex() operation
that can be used as a fallback should we ever get new futex operations.
However, the existence of an exposed futex() fallback should never be a
reason to not provide a proper futex interface.

> I think it would have been harmful to users to insist that all unknown 
> ioctl uses go through the syscall function unless we've individually 
> reviewed and second-guessed the interface in every case - it would just 
> gratuitously complicate their code.  And I think the same applies to 
> futex.

That may be a proper analogy if we'd be looking at adding a futex API
while the kernel-level set of futex operations still evolved.  But right
now, we're looking at a pretty stable set of operations, and we have
documentation from the kernel that actually describes the intended
logical API (which is then transformed into the multiplexing scheme
used).

Thus, if people start with the futex docs to understand how the futex
operations work -- and they should do that --, then what complicates a
futex interface would be the multiplexing interface itself (e.g., the
wild parameter reuse), not the alternative interface I outlined.

Also, it's not like it should take us long to decide on a proper futex
interface, nor would that matter much given that we haven't had any
futex interface for a long time.  Or are you thinking about other kinds
of complications?

And I still don't really see the harm for users.  Can you be more
specific?  Are you concerned about availability, or timely availability,
or deviation to the lowest-level OS interface, or usability, or ...?

> The fact that, with hindsight, we might not have designed an API 
> the way it was in fact designed does not mean we should embed that 
> viewpoint in the choice of APIs provided to users.

If we have the hindsight, why should we ignore it?  It's not even just
our hindsight in this case, we're following the kernel docs mostly.