On Fri, Mar 25, 2022 at 1:46 AM Karel Zak <kzak@xxxxxxxxxx> wrote: > > I can imagine something like getvalues(2) in lsblk (based on /sys) or > in lsfd (based on /proc; lsof replacement). I really would be very hesitant to add new interfaces for completely specialty purposes. As others have mentioned, this has been tried for much more fundamental reasons (that whole "open-and-read" thing), and it hasn't been an obvious improvement. It *could* possibly be an improvement if it would allow us to take advantage of special server-side operations in a networked filesystem (ie like the whole "copy_file_range" kinds of interfaces that allow server-side things) where you need to transfer less data, or need fewer back-and-forth operations. And even that is clearly questionable, with some of those network file interfaces basically not having been used in real world situations in the past, so.. (Also, with "copy_file_range" we not only had others actively doing it, but the wins were "several orders of manitude", so even if it was fairly rare, it was _so_ big that it was worth doing anyway). With the "open-and-read" thing, the wins aren't that enormous. And getvalues() isn't even that. It's literally a speciality interface for a very special thing. Yes, I'm sure it avoids several system calls. Yes, I'm sure it avoids parsing strings etc. But I really don't think this is something we want to do unless people can show enormous and real-world examples of where it makes such a huge difference that we absolutely have to do it. Linus