From: Alejandro Colomar <alx@kernel.org>
To: наб <nabijaczleweli@nabijaczleweli.xyz>
Cc: linux-man@vger.kernel.org
Subject: Re: [PATCH] futex_waitv.2: new page
Date: Sat, 7 Feb 2026 22:50:57 +0100 [thread overview]
Message-ID: <aYezLCRammSoqjTM@devuan> (raw)
In-Reply-To: <3en4ifc2b6upp4ufedhajhyikvmpc2yrosl5hpftszlzsdy3b4@tarta.nabijaczleweli.xyz>
[-- Attachment #1: Type: text/plain, Size: 2917 bytes --]
On 2026-02-07T20:16:36+0100, наб wrote:
> Hi!
Hi!
>
> On Sat, Feb 07, 2026 at 07:57:03PM +0100, Alejandro Colomar wrote:
> > On 2026-02-07T13:49:12+0100, наб wrote:
> > > +.TP
> > > +.B EINVAL
> > > +.I nr_futexes
> > > +was not between 1 and
> > > +.B FUTEX_WAITV_MAX
> > > +(128).
> >
> > In this case I would like to see a range. "Between" doesn't make it
> > clear whether the bounds are inclusive or exclusive or combined.
>
> "nr_futexes was not in [1, FUTEX_WAITV_MAX (128)]."?
Yeah, that sounds quite good.
> > > +.TP
> > > +.B EAGAIN
> > > +The value pointed to by
> > > +.I uaddr
> > > +was not equal to the expected value
> > > +.I val
> > > +at the time of the call.
> > > +.IP
> > > +.BR Note :
> > > +on Linux, the symbolic names
> > > +.B EAGAIN
> > > +and
> > > +.B EWOULDBLOCK
> > > +(both of which appear in different parts of the kernel futex code)
> > > +have the same value.
> >
> > Should we use wording like in read(2)? It uses
> >
> > .TP
> > .BR EAGAIN " or " EWOULDBLOCK
> >
> > Or do you have reasons to prefer your wording?
>
> That's what FUTEX_WAIT(2const) says and that's the most-sister page
> I copied this from (it is pretty crazy wording). But
Makes sense, thanks!
> $ git grep 'hich appear in different'
> man/man2/futex_waitv.2:(both of which appear in different parts of the kernel futex code)
> man/man2const/FUTEX_WAIT.2const:(both of which appear in different parts of the kernel futex code)
> man/man2const/FUTEX_WAIT_BITSET.2const:(both of which appear in different parts of the kernel futex code)
> man/man2const/FUTEX_WAIT_REQUEUE_PI.2const:(both of which appear in different parts of the kernel futex code)
> so those want to get those gone as well.
Yeah, if you feel like cleaning up the wording in all of them, that
would help. On the other hand, I would understand if you don't feel
like doing that. Do what you prefer. :)
>
> > > +.SH NOTES
> >
> > Maybe CAVEATS?
>
> idk if it's a caveat... the futex(2) API family functionally hard-codes
> FUTEX2_SIZE_U32 into every operation and it's not a caveat there.
> And, having just seen a lot of futex kernel code, it abuses futexes
> being 4 bytes /so much/. I don't think anyone's expecting to have
> non-4-byte futexes any time soon. So this is more like a notable curio
> to explain why you need FUTEX2_SIZE_U32 at all than "beware this missing API".
> Y/N?
Agree.
>
> > > +#include <linux/futex.h>
> > > +#include <sys/syscall.h>
> > > +#include <time.h>
> > > +#include <unistd.h>
> > > +\&
> >
> > What's the distinction between the two include groups?
> Top 4 are for the syscall from SYNOPSIS,
> rest are for application code.
I would merge them. After all, we already have the SYNOPSIS for that.
Cheers,
Alex
>
> Best,
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-02-07 21:51 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-07 12:49 [PATCH] futex_waitv.2: new page наб
2026-02-07 18:57 ` Alejandro Colomar
2026-02-07 19:16 ` наб
2026-02-07 21:50 ` Alejandro Colomar [this message]
2026-02-07 22:00 ` [PATCH v2] " наб
2026-02-09 22:35 ` Alejandro Colomar
2026-02-10 14:17 ` наб
2026-02-10 14:30 ` Alejandro Colomar
2026-02-10 15:54 ` Kristoffer Haugsbakk
2026-02-10 18:39 ` Alejandro Colomar
2026-02-11 7:35 ` Jeff King
2026-02-11 8:15 ` Kristoffer Haugsbakk
2026-02-11 15:43 ` Junio C Hamano
2026-02-10 16:54 ` Junio C Hamano
2026-02-10 17:11 ` Kristoffer Haugsbakk
2026-02-10 18:44 ` Alejandro Colomar
2026-02-10 20:05 ` Alejandro Colomar
2026-02-10 20:32 ` [PATCH v3] " наб
2026-02-10 21:11 ` Alejandro Colomar
2026-02-11 4:00 ` [PATCH v4] " наб
2026-02-11 13:23 ` Alejandro Colomar
2026-02-11 13:51 ` [PATCH v5] " наб
2026-02-11 14:15 ` [PATCH v6] " наб
2026-02-11 14:31 ` Alejandro Colomar
2026-02-11 14:44 ` [PATCH v7] " наб
2026-02-11 14:55 ` Alejandro Colomar
2026-02-11 14:59 ` наб
2026-02-11 15:13 ` Alejandro Colomar
2026-02-14 17:32 ` Alejandro Colomar
2026-02-14 19:30 ` [PATCH v8] " наб
2026-02-14 20:03 ` Alejandro Colomar
2026-02-14 20:48 ` [PATCH v9] " наб
2026-02-15 18:18 ` Alejandro Colomar
2026-02-15 19:00 ` [PATCH v10] " наб
2026-02-16 0:32 ` Alejandro Colomar
2026-02-16 14:20 ` [PATCH v11] " наб
2026-02-16 14:50 ` Alejandro Colomar
2026-02-16 20:43 ` [PATCH v12] " наб
2026-02-17 13:07 ` Alejandro Colomar
2026-02-17 14:31 ` [PATCH v13] " наб
2026-02-17 15:46 ` Alejandro Colomar
2026-02-17 16:17 ` наб
2026-02-18 0:31 ` Alejandro Colomar
2026-02-11 14:28 ` [PATCH v5] " Alejandro Colomar
2026-02-18 0:41 ` [PATCH v1 0/1] futex_waitv.2: Move text to a new PARAMETERS section Alejandro Colomar
2026-02-18 0:41 ` [PATCH v1 1/1] man/man2/futex_waitv.2: " Alejandro Colomar
2026-02-18 20:16 ` [PATCH v1 0/1] futex_waitv.2: " наб
2026-02-18 20:26 ` Alejandro Colomar
2026-02-18 20:30 ` наб
2026-02-18 20:33 ` Alejandro Colomar
2026-02-18 20:40 ` G. Branden Robinson
2026-02-18 21:28 ` Alejandro Colomar
2026-02-18 22:04 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYezLCRammSoqjTM@devuan \
--to=alx@kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=nabijaczleweli@nabijaczleweli.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox