Re: [PATCH v3 2/3] fs: fuse: add backing_files control file

[Chen Linxuan]

On Tue, May 13, 2025 at 3:58 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Tue, 13 May 2025 at 09:39, Christian Brauner <brauner@xxxxxxxxxx> wrote:
>
> > No, the xattr interface is ugly as hell and I don't want it used as a
> > generic information transportation information interface. And I don't
> > want a single thing that sets a precedent in that direction.
>
> You are getting emotional and the last messages from you contain zero
> technical details.
>
> I know about the buffer sizing one, can you describe your other gripes?
>
> > > But if the data is inherently variable sized, adding specialized
> > > interface is not going to magically solve that.
> > >
> > > Instead we can concentrate on solving the buffer sizing problem
> > > generally, so that all may benefit.
> >
> > The xattr system call as far as I'm concerned is not going to be pimped
> > to support stuff like that.
>
> Heh?  IIRC there were positive reactions to e.g. "O_XATTR", it just
> didn't get implemented.  Can try to dig this up from the archives.
>
> > Then by all means we can come up with a scheme in procfs that displays
> > this hierarchically if we have to.
>
> Yeah, perhaps it's doable.

In my opinion, adding relevant directories and nodes under procfs does not seem
to be much different from what I did in this patch by adding nodes
under /sys/fs/fuse.
This kind of solution would still be a somewhat “non-generic” approach.
For io_uring, scm_rights, and fuse backing files,
these newly added files or directories will eventually have their own
specific names.

I’m starting to wonder: is it really meaningful to pursue “genericity”
in this context?
Especially considering that io_uring already has its own “non-generic” handling.
For introducing a new way to expose kernel-held file resources,
would the maintainers of these two features even be willing to
coordinate and make changes?

Thanks,
Chen Linxuan

>
> Thanks,
> Miklos
>
>