On Mon, May 12, 2025 at 10:27:19AM +0200, Miklos Szeredi wrote: > On Sun, 11 May 2025 at 11:56, Chen Linxuan <chenlinxuan@xxxxxxxxxxxxx> wrote: > > > I noticed that the current extended attribute names already use the > > namespace.value format. > > Perhaps we could reuse this naming scheme and extend it to support > > features like nested namespaces. > > Right. Here's a link to an old and long thread about this: > > https://lore.kernel.org/all/YnEeuw6fd1A8usjj@xxxxxxxxxxxxxxxxxxxxxxxxx/#r > > > > > For instance, in a situation like this: > > > > A fixed file 0 in an io_uring is a FUSE fd. > > This FUSE fd belongs to FUSE connection 64. > > This FUSE fd has a backing file. > > This backing file is actually provided by mnt_id=36. > > > > Running getfattr -m '-' /proc/path/to/the/io_uring/fd could return > > something like: > > > > io_uring.fixed_files.0.fuse.conn="64" > > io_uring.fixed_files.0.fuse.backing_file.mnt_id="36" > > io_uring.fixed_files.0.fuse.backing_file.path="/path/to/real/file" > > Yeah, except listxattr wouldn't be able to properly work in such > cases: it lacks support for hierarchy. > > The proposed solution was something like making getxattr on the > "directory" return a listing of child object names. > > I.e. getxattr("/proc/123/fd/12", "io_uring.fixed_files.") would return > the list of instantiated fixed file slots, etc... Sorry, I'm still very much opposed to using the xattr interface for this. It is as ugly as it can get and it is outright broken in various ways. And I don't want it used for more stuff in the future especially for VFS related information such as this.
