This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Principles for syscall wrappers, again
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Torvald Riegel <triegel at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: Rich Felker <dalias at libc dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Mon, 01 Jun 2015 14:42:56 +0100
- Subject: Re: Principles for syscall wrappers, again
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1505182114090 dot 16300 at digraph dot polyomino dot org dot uk> <20150519000918 dot GB17573 at brightrain dot aerifal dot cx> <1432630525 dot 3077 dot 36 dot camel at triegel dot csb> <20150526151000 dot GA17573 at brightrain dot aerifal dot cx> <alpine dot DEB dot 2 dot 10 dot 1505281648440 dot 16930 at digraph dot polyomino dot org dot uk> <1432888653 dot 30849 dot 146 dot camel at triegel dot csb> <alpine dot DEB dot 2 dot 10 dot 1505291103540 dot 2439 at digraph dot polyomino dot org dot uk> <1432900697 dot 30849 dot 178 dot camel at triegel dot csb> <alpine dot DEB dot 2 dot 10 dot 1505291301400 dot 18021 at digraph dot polyomino dot org dot uk> <1432908585 dot 30849 dot 213 dot camel at triegel dot csb> <alpine dot DEB dot 2 dot 10 dot 1505291524290 dot 27491 at digraph dot polyomino dot org dot uk> <1432923248 dot 4832 dot 40 dot camel at triegel dot csb>
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