On 2025-08-27 15:48, Aleksa Sarai wrote:
On 2025-08-27, Paul Eggert <eggert@xxxxxxxxxxx> 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.
