This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Principles for syscall wrappers, again
- From: Rich Felker <dalias at libc dot org>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Mon, 1 Jun 2015 10:51:50 -0400
- Subject: Re: Principles for syscall wrappers, again
- Authentication-results: sourceware.org; auth=none
- References: <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, Jun 01, 2015 at 02:42:56PM +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.
> - 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.
Another risk of using the names futex_wake/futex_wait is that they may
clash with different wrappers by the same name that an application has
used, making refitting the code to use sys/futex.h versions more work
and more error-prone.
Still I'd rather have both approaches in sys/futex.h than neither...
> 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
Thanks for doing the research here.
Rich