Re: Principles for syscall wrappers, again

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2015-05-29 at 10:07 -0400, Rich Felker wrote:
> On Fri, May 29, 2015 at 01:58:17PM +0200, 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 that would solve the technical problem, yes.
> 
> > > 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 would fully support having both a full-featured futex() multiplexing
> function and individual clean-API wrappers for common operations. I
> would even be fine with only the latter being part of the
> "cross-platform GNU API" and the former being Linux-only, though of
> course I would prefer both be treated as first-class APIs.

Good.

Would you want futex() that is cancellable for some ops specifically, or
would you be fine with a cancellable syscall?  Would you prefer having
futex()?

> > > 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).
> 
> Look at it this way: if the kernel adds a new futex command, how long
> will it take to get glibc support for it with multiplexer vs
> individual functions? And to get that support deployed into mainstream
> distros? :-)

That depends on the distro.  If the kernel is as old as glibc, there's
no problem... :)