4 ms·
In this case, `lsof` is a relatively lightweight parser for /proc. The /proc filesystem API is amazingly stable. The unstable ABI is internal to the kernel itse
by akerl_ 8y ago
In this case, `lsof` is a relatively lightweight parser for /proc. The /proc filesystem API is amazingly stable. The unstable ABI is internal to the kernel itself; the interaction with userspace is where backwards compat is held as the highest guiding principle (see Linus's remarks about breaking userspace).
By contrast, lsof can change output at any time. I've not done enough parsing of lsof to be familar with past changes, but have seen meaningful changes in the default output of lsblk, df, and other core CLI tools that wrap system information.
- rabidcondor 8y agomacOS, with its BSD roots, doesn't have a proc filesystem.
- comex 8y agoIf anyone's curious: Traditionally, lsof on BSD would just open /dev/kmem and read the info directly out of the kernel's data structures! It still does that on FreeBSD, and used to do it on macOS prior to 2006, when Apple added the more sensible (and stable) libproc.h API in one of the Tiger software updates. Sloth dates back to 2004, at which point parsing lsof's output would definitely have been a more sensible choice than replicating the kmem parsing code. On the other hand, if I were writing something like Sloth today, though, I'd use libproc, because I think it'd be easier overall, and it would also make it more feasible to improve the core functionality (like adding a progress bar or lazy querying). However, lsof does have a flag (-F) to specify how to format its output, explicitly documented in the man page as being intended for other programs that want to parse its output, implying that it will remain stable. And Sloth uses this flag. Thus, even from a modern perspective, its approach is perfectly reasonable.
- lawnchair_larry 8y agoHuh, so that means you need root to run lsof on freebsd?
- saagarjha 8y agolsof seems to be setgid on FreeBSD (group kmem).