On Wed, May 14, 2014 at 1:23 PM, Carlos O'Donell [off-list ref] wrote:

On 05/14/2014 03:03 PM, Michael Kerrisk (man-pages) wrote:

quoted

quoted

However, unless I'm sorely mistaken, the larger problem is that glibc
removed the futex() call entirely, so these man pages don't describe

I don't think futex() ever was in glibc--that's by design, and
completely understandable: no user-space application would want to
directly use futex(). (BTW, I mispoke in my earlier mail when I said I
wanted documentation suitable for "writers of library functions" -- I
meant suitable for "writers of *C library*".)

I fully agree with Michael here.

The futex() syscall was never exposed to userspace specifically because
it was an interface we did not want to support forever with a stable ABI.
The futex() syscall is an implementation detail that is shared between
the kernel and the writers of core runtimes for Linux.

The fact that the futex() syscall is out of date is my fault, is the fault
of Linux kernel developers, etc. etc., we should all have reached out to
Michael with patches to keep this developer-centric documentation updated.

I realize that this is out of scope for linux-abi, but I *stongly*
disagree with this notion.  futex() needs to be just as stable as
anything else: old glibc versions must continue to work.  I just
jumped through a bunch of hoops to keep a single glibc patch release
in OpenSUSE 9 working in a maintainable way; breaking futex will break
far more than that.

Additionally, at least the FUTEX_WAIT and FUTEX_WAKE operations are
extremely useful, and they can do things that are tedious at best
using mutexes and condvars.  It's a simple API to use.  I use it, and
I've seen plenty of other open-source apps using the futex API
directly.

I think the best way forward might be to try to convince the glibc
maintainers to add the wrapper.

--Andy