Principles for syscall wrappers, again

[Szabolcs Nagy]

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.
- libgomp uses SYS_futex and SYS_gettid (and it has inline asm to call
futex syscall directly on various archs).
- libcilkrts uses SYS_gettid.
- libitm uses SYS_futex.

> 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.

debian codesearch finds these futex users:

android-androresolvd
aqsis (includes tbb)
capnproto
chromium-browser
ghdl
groonga
haproxy
libxshmfence
linux-tools
mariadb-10.0 (includes groonga)
mumble
openimageio (includes tbb)
percona-xtrabackup
phantomjs (includes qt base)
qt4-x11 (includes qt base)
qtbase-opensource-src
rr
sbcl
simgrid
stress-ng
tbb