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. 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 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 And by recursivity I mean that third point. Thanks, Miklos
