On 2025-08-27, Paul Eggert <eggert@xxxxxxxxxxx> wrote: > 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. While O_* and RESOLVE_* flags are trivial to detect (since you can always pass -EBADF to force a non-EINVAL error), my goal was to have a unified interface for extensible-struct syscalls in this department. > 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. I mean, the kernel definition doesn't mark the syscall argument as "const" so making it const in glibc also means maintaining a divergence from the kernel. Of course, glibc does this for plenty of other syscalls so it's not my place to say which is better. My intention was just to say that this *was* intentiona (which was how I understood the initial question that I was Cc'd onl, and if you feel that intention is misguided / doesn't mesh with what glibc wants then that's your call. > > 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 was just giving it as an example where "just try it" is not really ideal for userspace today. clone3(2) is an extensible-struct syscall that needs this. > 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. My only concern is that it would break recompiles if/when we change it back. If that is not a concern for glibc as a project then you are of course free to do whatever makes sense for glibc. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
Attachment:
signature.asc
Description: PGP signature
