Principles for syscall wrappers, again

[Rich Felker]

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.

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

Rich