This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Add futex wrapper to glibc?
- From: Darren Hart <dvhart at infradead dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Rich Felker <dalias at libc dot org>, Roland McGrath <roland at hack dot frob dot com>, Torvald Riegel <triegel at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>, Michael Kerrisk <mtk dot manpages at gmail dot com>
- Date: Wed, 29 Oct 2014 19:03:16 -0700
- Subject: Re: Add futex wrapper to glibc?
- Authentication-results: sourceware.org; auth=none
- References: <1410881785 dot 4967 dot 292 dot camel at triegel dot csb> <20140917194100 dot 23B722C26C5 at topped-with-meat dot com> <1410983178 dot 27838 dot 27 dot camel at triegel dot csb> <20140917195918 dot 6F06C2C3974 at topped-with-meat dot com> <20140917231708 dot GC23797 at brightrain dot aerifal dot cx> <544953F7 dot 1020607 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1410232050160 dot 19073 at digraph dot polyomino dot org dot uk>
On Thu, Oct 23, 2014 at 09:06:17PM +0000, Joseph S. Myers wrote:
> On Thu, 23 Oct 2014, Carlos O'Donell wrote:
>
> > We are IMO at the stage where futex is stable, few things are changing,
> > and with documentation in place, I would consider adding a futex wrapper.
> > However, per other discussions on errors, I'd actually add a non-trivial
> > C wrapper to enforce that the kernel does not return error codes that
> > are unexpected.
>
> I don't think that makes sense for futex. I think such checks only make
> sense where glibc is making use of futex within its own code - there it
> may sometimes be useful to sanity-check results match glibc's
> expectations. I also think it's desirable for any such syscall wrapper to
> be usable with futex operations that may be added to the kernel in future
> (i.e. someone should only need new kernel headers to build code using new
> operations, not a new glibc binary that knows how to check things for
> those new operations).
Agreed, let the caller deal with the return values. When used directly, glibc
should not be acting on any of the return codes as they are needed by the
implementation (which is outside of glibc).
--
Darren Hart
Intel Open Source Technology Center