On 2025-08-27, Paul Eggert <eggert@xxxxxxxxxxx> wrote: > 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? "Just try it" leads to programs that have to test dozens of flag combinations for syscalls at startup, and for many syscalls you cannot "just try" whether the new flag works (think of a new shutdown(2) flag, or most clone3(2) flags). What you end up having to do is create an elaborate setup where if the flag works you get an error (but not -EINVAL!) so that you can be fairly confident that you didn't modify the system when doing the check. As someone who has to write this boilerplate whenever I need to use most system calls, this really **really** sucks. In some cases you can just try it and then fallback (caching whether it was supported), but in a lot of programs it is preferable to know well in advance whether a feature is supported. A simple example would be mounts -- if MOUNT_BENEATH is not supported then you need to structure how you construct your mount tree differently to try to emulate the same behaviour. This means that not knowing if MOUNT_BENEATH is supported upfront causes you to redo a lot of work in the fallback case. If changing id-mappings for mounts hadn't required adding a new syscall, this would've also been an issue for programs that needed to change the ID-mappings of mounts. Some kind of "just tell me what flags are supported" mechanism avoids this problem by telling you in one shot what features are supported (so newer programs can take advantage of them). Most systems that expect to be extended over time have something like this, but it's usually in the form of string-based feature names (/sys/kernel/cgroup/features, for instance). I wouldn't be against such an idea (if we could actually guarantee that everyone actually used it), but something similar was proposed back in 2020 and never happened -- CHECK_FIELDS is a very simple solution to the problem that works for the most common case and can be implemented per-syscall. I've added linux-api to Cc, as I'm sure there are plenty of other ideas on how to solve this. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
Attachment:
signature.asc
Description: PGP signature
