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 > >
