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

[Paul Eggert]

On 2025-08-26 22:58, Aleksa Sarai wrote:
> Personally I think both approaches are less than ideal, and having rich
> feature flags for the entire system would be better but I don't think
> this is something that would be feasible to apply to everything in the
> entire kernel.

Agreed. But I'm not seeing how a hypothetical "give me the supported 
flags" flag would be useful enough to justify the flag.

I'm looking at this from the user point of view, and it is not ringing a 
bell for me. Granted, the current "try the flag combination you want and 
see whether it works" is not ideal, but it's accurate (which is not 
always true for "give me the supported flags" flag) and you need to do 
it anyway (because the "give me the supported flags" flag is inherently 
inaccurate), so why bother with a "give me the supported flags" flag?

Here's an example. Suppose we want to extend openat2 so that it also 
does the equivalent of statx atomically with the open, to avoid some 
races with the current openat/fstat pair of system calls. Under the 
approach you're proposing, I suppose we could extend struct open_how so 
that it has a new struct statx member, add new flags to be put into 
struct open_how's flags member, and programs would be able to query the 
new flags via a "give me the supported flags" call.

But in this scenario, the "give me the supported flags" flag is useless. 
If I'm an old program I can't use the new flags even if I detect them 
because my struct open_how is too small. And if I'm a new program I can 
simply use the new flags - and even if I tested for the new flags (with 
the "give me the supported flags" flag) I'd have to test the result 
anyway because perhaps the new flags are not supported for this 
particular flag combination or file.

What specific scenario would make the "give me supported flags" flag 
worth the hassle of supporting and documenting and testing such a flag?