On Tue, Aug 18, 2020 at 10:53 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> Basically, I think a rough rule of thumb can and should be:
>
> - stuff that the VFS knows about natively and fully is clearly pretty
> mount-agnostic and generic, and can be represented in whatever
> extended "struct statfs_x" directly.
>
> - anything that is variable-format and per-fs should be expressed in
> the ASCII buffer
>
> Look at our fancy new fs_context - that's pretty much what it does
> even inside the kernel. Sure, we have "binary" fields there for core
> basic information ("struct dentry *root", but also things like flags
> with MNT_NOSUID), but the configuration stuff is ASCII that the
> filesystem can parse itself.
>
> Exactly because some things are very much specific to some
> filesystems, not generic things.
>
> So we fundamentally already have a mix of "standard FS data" and
> "filesystem-specific options", and it's already basically split that
> way: binary flag fields for the generic stuff, and ASCII text for the
> odd options.
Okay.
Something else: do we want a separate statmount(2) or is it okay to
mix per-mount and per-sb attributes in the same syscall?
/proc/mounts concatenates mount and sb options (since it copies the
/etc/mtab format)
/proc/self/mountinfo separates per-mount and per-sb data into
different fields at least, but the fields themselves are mixed
If we are introducing completely new interfaces, I think it would make
sense to separate per-mount and per-sb attributes somehow. Atomicity
arguments don't apply since they have separate locking. And we
already have separate interfaces for configuring them...
Thanks,
Miklos
