On Wed, 4 May 2022 at 00:43, Dave Chinner [off-list ref] wrote:

"values" is a very generic name - probably should end up being
something more descriptive of the functionality is provides,
especially if the header file is going to be dumped in
include/linux/. I don't really have a good suggestion at the moment,
though.

The obvious ones are stat and attr, which are taken already.   Info is
probably too generic as well.

Ideas are welcome.

....

quoted

+
+enum {
+     VAL_MNT_INFO,
+};
+
+static struct val_desc val_mnt_group[] = {
+     { VD_NAME("info"),              .idx = VAL_MNT_INFO             },
+     { }
+};

....

quoted

+
+
+static struct val_desc val_toplevel_group[] = {
+     { VD_NAME("mnt:"),      .get = val_mnt_get,     },
+     { VD_NAME("mntns:"),    .get = val_mntns_get,   },
+     { },
+};

I know this is an early POC, my main question is how do you
envisiage this table driven structure being extended down from just
the mount into the filesystem so we can expose filesystem specific
information that isn't covered by generic interfaces like statx?

I was thinking of adding a i_op callback.   The details are a bit
fuzzy, since the vfs and the fs would have to work together when
listing the attributes and possibly also when retrieving the attribute
itself (think mount options).

Thanks,
Miklos