Jann Horn <jannh@xxxxxxxxxx> wrote:
> Ewww. So basically, having one static set of .fsinfo_attributes is not
> sufficiently flexible for everyone, but instead of allowing the
> filesystem to dynamically provide a list of supported attributes, you
> just duplicate the super_operations? Seems to me like it'd be cleaner
> to add a function pointer to the super_operations that can dynamically
> fill out the supported fsinfo attributes.
>
> It seems to me like the current API is going to be a dead end if you
> ever want to have decent passthrough of these things for e.g. FUSE, or
> overlayfs, or VirtFS?
Ummm...
Would it be sufficient to have a function that returns a list of attributes?
Or does it need to be able to call to vfs_do_fsinfo() if it supports an
attribute?
There are two things I want to be able to do:
(1) Do the buffer wrangling in the core - which means the core needs to see
the type of the attribute. That's fine if, say, afs_fsinfo() can call
vfs_do_fsinfo() with the definition for any attribute it wants to handle
and, say, return -ENOPKG otherways so that the core can then fall back to
its private list.
(2) Be able to retrieve the list of attributes and/or query an attribute.
Now, I can probably manage this even through the same interface. If,
say, seeing FSINFO_ATTR_FSINFO_ATTRIBUTES causes the handler to simply
append on the IDs of its own supported attributes (a helper can be
provided for that).
If it sees FSINFO_ATR_FSINFO_ATTRIBUTE_INFO, it can just look to see if
it has the attribute with the ID matching Nth and return that, else
ENOPKG - again a helper could be provided.
Chaining through overlayfs gets tricky. You end up with multiple contributory
filesystems with different properties - and any one of those layers could
perhaps be another overlay. Overlayfs would probably needs to integrate the
info and derive the lowest common set.
David
