This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Add futex wrapper to glibc?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: 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>, Darren Hart <dvhart at infradead dot org>, Michael Kerrisk <mtk dot manpages at gmail dot com>
- Date: Thu, 23 Oct 2014 21:58:54 -0400
- 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 10/23/2014 05:06 PM, Joseph S. Myers 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).
I concede.
My worry is the mess with sched_[sg]etaffinity where the kernel syscall
and userspace API are different.
Your point " * If there's a glibc function that's not quite a direct
wrapper of the syscall but provides all the functionality of it that
can usefully be used in a program using glibc, there is no need to
add a wrapper to glibc." covers that though.
I've added your notes to the wiki:
https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers
Cheers,
Carlos.