Principles for syscall wrappers, again

[Torvald Riegel]

On Mon, 2015-06-01 at 14:42 +0100, Szabolcs Nagy wrote:
> On 29/05/15 19:14, Torvald Riegel wrote:
> > On Fri, 2015-05-29 at 15:34 +0000, Joseph Myers wrote:
> >> What would be bad is letting discussion of a multiple-function interface 
> >> obstruct consideration and acceptance of a patch adding the basic 
> >> interface.
> > 
> > Sure, but we haven't actually found out whether there would be any
> > obstruction.  Rich says he wouldn't mind having both, others haven't
> > commented.  What's your thought on having both?  Are you opposed to
> > having both, or where do you think the obstruction would come from?
> 
> i think it would be nice if ppl could stop calling syscall directly
> (eg. it can be problematic on ilp32 syscall abi).
> 
> i assume providing the kernel futex api (as a variadic function)
> is the easiest way to get there.
> 
> eg. syscall users in gcc on linux:
> 
> - libstdc++ uses SYS_futex.

We use syscall() here, but code would use a proper futex API if
available.  If the latter would offer a ready-to-use timedwait with
absolute timeouts, code that duplicates what we do in glibc could be
removed.

> - libgomp uses SYS_futex and SYS_gettid (and it has inline asm to call
> futex syscall directly on various archs).

I believe we'd also use wrappers here.

> - libitm uses SYS_futex.

Same as for libstdc++.  Has it's own futex_wait and futex_wake wrappers
already.

> > I mean, in glibc we already do use a different interface than futex(),
> > and always have, right?  And IIRC, futexes have been developed at least
> > with a lot of input from glibc.  Isn't that enough indication that just
> > offering futex() wouldn't be what people actually need?
> 
> some projects already use syscall(SYS_futex,...).
> 
> some of them indeed wrap it as futex_wake/futex_wait but not all.

Good idea using the Debian code search.  Here's what I found for the
first few hits returned in my search ("futex filetype:c", ignoring those
packages that don't seem to actually use futexes, but just include the
syscall numbers, for example):

> mariadb-10.0 (includes groonga)
- groonga seems to have use futex_wake but futex_wait is just a sleep?

openmprtl:
-seems to build its own locks based on syscall()

qemu: creates it's own futex_wait etc. wrappers

> simgrid
- creates it's own futex_wait etc. wrappers based on syscall()

> tbb
- creates it's own futex_wait etc. wrappers

wine:
- creates it's own futex_wait and _wake wrappers

I haven't looked further, but based on that sample it seems that quite a
few projects see a need to build and use their own custom wrappers.
That indicates to me that futex() isn't quite what they were looking
for.