This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Principles for syscall wrappers, again
- From: Torvald Riegel <triegel at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, Rich Felker <dalias at libc dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 03 Jun 2015 22:08:24 +0200
- 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> <556C6160 dot 201 at arm dot com>
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.