Re: Principles for syscall wrappers, again

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.

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.  Sometimes we might need to change the futex 
implementation in libc to adjust cancellation handling for new operations, 
but that's no different from the adjustment of open regarding O_TMPFILE 
(bug 17523).  Providing access to new operations - at the most specific 
level at which this can be done, rather than forcing everything through 
syscall - is useful even if occasionally they do need libc changes, as 
with O_TMPFILE.

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.  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.  This is a C library 
and in C we should provide a range of interfaces at different levels, some 
easier to use and some closer to the underlying OS interfaces.

-- 
Joseph S. Myers
joseph@codesourcery.com