[PATCH v4] linux: Add openat2 (BZ 31664)

[Paul Eggert]

On 2025-08-27 15:48, Aleksa Sarai wrote:
> On 2025-08-27, Paul Eggert <eggert@cs.ucla.edu> wrote:
>> What specific scenario would make the "give me supported flags" flag worth
>> the hassle of supporting and documenting and testing such a flag?
> 
> "Just try it" leads to programs that have to test dozens of flag
> combinations for syscalls at startup,

Although that sort of thing can indeed be a problem in general, I don't 
see how it's a problem for openat2 in particular.

The issue here is whether openat2's API should reflect current behavior 
(where the HOW argument is pointer-to-const) or a potential future 
behavior (where the kernel might modify the struct that HOW points to, 
if some hypothetical future flag is set in that struct). I am skeptical 
that this hypothetical situation is so plausible that it justifies the 
maintenance hassle of a glibc API that doesn't correspond to how openat2 
currently behaves.


> A simple example would be mounts -- if MOUNT_BENEATH is not supported

I don't understand this example. Are you talking about <linux/mount.h>'s 
MOVE_MOUNT_BENEATH? That's a move_mount flag, and I don't see what that 
has to do with openat2. Or are you saying that openat2 might not support 
<linux/openat2.h>'s RESOLVE_BENEATH flag? Under what conditions might 
that be, exactly? Can you give some plausible user code to illustrate 
the openat2 example you're thinking of?

I still fail to understand how a hypothetical "give me the supported 
flags" openat2 flag would be useful enough to justify complicating the 
openat2 API today.