On Mon, 11 Mar 2024 at 14:25, Christian Brauner <brauner@xxxxxxxxxx> wrote: > Yeah, so with that I do agree. But have you read my reply to the other > thread? I'd like to hear your thoughs on that. The problem is that > mount(8) currently does: > > fsconfig(3, FSCONFIG_SET_FLAG, "usrjquota", NULL, 0) = -1 EINVAL (Invalid argument) > > for both -o usrjquota and -o usrjquota= For "-o usrjquota" this seems right. For "-o usrjquota=" it doesn't. Flags should never have that "=", so this seems buggy in more than one ways. > So we need a clear contract with userspace or the in-kernel solution > proposed here. I see the following options: > > (1) Userspace must know that mount options such as "usrjquota" that can > have no value must be specified as "usrjquota=" when passed to > mount(8). This in turn means we need to tell Karel to update > mount(8) to recognize this and infer from "usrjquota=" that it must > be passed as FSCONFIG_SET_STRING. Yes, this is what I'm thinking. Of course this only works if there are no backward compatibility issues, if "-o usrjquota" worked in the past and some systems out there relied on this, then this is not sufficient. > > (2) We use the proposed in-kernel solution where relevant filesystems > get the ability to declare this both as a string or as a flag value > in their parameter parsing code. That's not a VFS generic thing. > It's a per-fs thing. This encourages inconsistency between filesystems, but if there's no other way to preserve backward compatibility, then... > > (3) We burden mount(8) with knowing what mount options are string > options that are allowed to be empty. This is clearly the least > preferable one, imho. > > (4) We add a sentinel such as "usrjquota=default" or > "usrjquota=auto" as a VFS level keyword. I don't really understand how this last one is supposed to fix the issue. > In any case, we need to document what we want: > > https://github.com/brauner/man-pages-md/blob/main/fsconfig.md What's the plan with these? It would be good if "man fsconfig" would finally work. Thanks, Miklos