public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
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 --]

  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