Re: [PATCH v1 02/14] futex: Extend the FUTEX2 flags
From: "Arnd Bergmann" <arnd@arndb.de>
Date: 2023-08-01 06:03:13
Also in:
linux-arch, linux-mm, lkml
On Tue, Aug 1, 2023, at 00:43, Thomas Gleixner wrote:
On Mon, Jul 31 2023 at 23:33, Peter Zijlstra wrote:quoted
On Mon, Jul 31, 2023 at 11:14:11PM +0200, Thomas Gleixner wrote:quoted
--- a/include/uapi/linux/futex.h +++ b/include/uapi/linux/futex.h@@ -74,7 +74,12 @@ struct futex_waitv { __u64 val; __u64 uaddr; - __u32 flags; + union { + __u32 flags; + __u32 size : 2, + : 5, + private : 1; + }; __u32 __reserved; };Durr, I'm not sure I remember if that does the right thing across architectures -- might just work. But I'm fairly sure this isn't the only case of a field in a flags thing in our APIs. Although obviously I can't find another case in a hurry :/I know, but that doesn't make these things more readable and neither an argument against doing it for futex2 :)
...
Still that explicit bitfield does neither need comments nor does it leave room for interpretation.
It may be clear to the compiler, but without comments or
looking up psABI documentation I certainly wouldn't know
immediately which bits of the flags word overlay the bitfields
for a given combination of __BIG_ENDIAN/__LITTLE_ENDIAN
and __BIG_ENDIAN_BITFIELD/__LITTLE_ENDIAN_BITFIELD or
architectures with unusual struct alignment requirements
(m68k or arm-oabi).
I'd prefer to completely avoid the bitfield here. Maybe having
exclusive flags for each width would be less confusing, at the
cost of needing two more flag bits and a slightly more complicated
sanity check, or we could take an extra byte out of the __reserved
field to store the length.
Arnd