On Thu, Feb 20, 2020 at 1:59 PM David Howells <dhowells@xxxxxxxxxx> wrote: > 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. Hm - I guess just returning a list of attributes ought to be fine? Then AFS can just return one of its two statically-allocated attribute lists there, and a filesystem with more complicated circumstances (like FUSE or overlayfs or whatever) can compute a heap-allocated list on mount that is freed when the superblock goes away, or something like that?
