Add futex wrapper to glibc?

[Carlos O'Donell]

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.