Re: Principles for syscall wrappers, again

[Rich Felker <dalias at libc dot org>]

On Fri, May 29, 2015 at 04:15:11PM +0200, Torvald Riegel wrote:
> 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 strongly prefer having futex(). Using syscall() is conceptually a
bad idea except in arch-specific code. This is even more the case
nowadays with x32's wackiness where the published syscall() API (using
'long' for the variadic arguments) does not even work. But it's always
been the case that various syscalls have arch-specific variations that
you need to be aware of to use them safely -- things like different
argument orders, etc. And if you're ever in a situation where the libc
types differ from the kernel types, using syscall() is just wrong
there too. This would apply to futex, for example, if glibc eventually
has an option like _FILE_OFFSET_BITS but for time_t -- when time_t is
set to 64-bit, futex() would need to use the 64-bit timespec
structure. 

Even if not for that last issue (the only one that applies to futex),
though, users should not have to be aware of which syscalls are "safe"
to make with syscall() and which are not, and we shouldn't be
encouraging use of syscall() for non-arch-specific purposes.

Also, if you want to emulate futex() on a system that doesn't have the
same native API, that's not going to work for code calling
syscall(SYS_futex, ...).

Rich