Re: Principles for syscall wrappers, again

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 29 May 2015, Torvald Riegel wrote:

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

I think we should have such a variant - but again, that's non-exclusive of 
also providing futex bindings.

> 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 don't claim it is.  I don't object to someone proposing a patch adding 
multiple functions with different futex interfaces - I simply don't 
consider my principles to have anything to say on such a patch.

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

I'd expect people to look at "man futex" on their distribution, and to 
expect a C function with the interface described there.  I looked at the 
branch you referenced 
<http://git.kernel.org/cgit/docs/man-pages/man-pages.git/tree/man2/futex.2?h=draft_futex> 
and I still don't see descriptions of the different C interfaces you 
describe.

Now, if the kernel stops providing the futex syscall in the asm-generic 
API for new architectures, instead providing separate syscalls, I'd 
consider that a strong indication that the interface *is* obsolete (and so 
excluded by my principles).  Or even if it states somewhere that new 
operations will use new syscalls and no new operations will be added to 
the existing syscall.

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

All of these.  I think glibc will be more useful in practice if we are 
more willing to delegate certain areas of low-level API design and 
implement APIs designed in the Linux kernel community like we do with 
POSIX APIs.  I think this discussion has illustrated my point: discussions 
here of the detailed design of such APIs get into ratholes, consuming 
limited resources (look at the size of the patch review backlog in 
patchwork), and so we should have principles that as far as possible 
delegate the design to external communities and respect their choices, 
reducing the set of choices needing review here.  Only in the cases where 
there isn't a suitable external API do we then need to do the detailed 
design ourselves.

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

Because whatever the issues with the kernel API, at least it's an API 
people know and can see in their futex manpages.

If you wish to define a more precise rule for determining the kernel's 
intended API - for determining the set of userspace C functions intended 
to correspond to a C syscall - that's fine, as long as it's generally 
clear how to apply that rule.  What I don't want is detailed redesign of 
APIs in the absence of strong evidence of kernel intent.

-- 
Joseph S. Myers
joseph@codesourcery.com