On Mon, May 12, 2025 at 12:06:19PM +0200, Miklos Szeredi wrote: > On Mon, 12 May 2025 at 11:23, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > The way I see it is, generic vs. specialized have pros and cons > > There is no clear winner. > > Therefore, investing time on the getxattr() direction without consensus > > with vfs maintainer is not wise IMO. > > AFAIU Christian is hung up about getting a properly sized buffer for the result. 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. > 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. > > > The problem I see with this scheme is that it is not generic enough. > > If lsof is to support displaying fuse backing files, then it needs to > > know specifically about those magic xattrs. > > Yeah, I didn't think that through. Need some *standard* names. > > > Because lsof only displays information about open files, I think > > it would be better to come up with a standard tag in fdinfo for lsof > > to recognize, for example: > > > > hidden_file: /path/to/hidden/file > > hidden_files_list: /path/to/connections/N/backing_files > > Ugh. > > > Making an interface more hierarchic than hidden_files_list: > > is useless because lsof traverses all fds anyway to filter by > > name pattern and I am very sceptical of anyone trying to > > push for an API get_open_fds_by_name_pattern()... > > The problem is that hidden files are hidden, lsof can't traverse them > normally. It would be good to unhide them in some ways, and for me > that would at least mean that you can > > 1) query the path (proc/PID/fd/N link) > 2) query fdinfo > 3) query hidden files Then by all means we can come up with a scheme in procfs that displays this hierarchically if we have to.
