4 ms·

Are you sure? I know BSDs use kvm_getprocs, but I don't know what the comparable sys call would have been on Linux. FWIW, /proc was added in Linux v0.97.3, Sep

Are you sure? I know BSDs use kvm_getprocs, but I don't know what the comparable sys call would have been on Linux. FWIW, /proc was added in Linux v0.97.3, September 1992, which is early enough I couldn't find ps source for linux earlier then that date.

yjftsjthsd-h 2y ago
The post you're replying to didn't say "on Linux" - IIRC, unix ps worked by reading /dev/kmem or so Edit: My mistake, it was /dev/mem - https://github.com/lsahn-gh/unix-v6/blob/master/source/s2/ps.c#L100 https://github.com/lsahn-gh/unix-v6/blob/master/source/s2/ps...
- upon_drumhead 2y ago
  Agh, completely fair. The topic was about Linux and I incorrectly presumed that the original comment was made in the same context. My mistake.
donio 2y ago
I remember this too. Very early on there were both proc and a /dev/kmem versions of ps and maybe top too. Yep, found it: https://www.ibiblio.org/pub/historic-linux/ftp-archives/sunsite.unc.edu/Sep-29-1996/system/Status/ps/INDEX.html https://www.ibiblio.org/pub/historic-linux/ftp-archives/suns... And the Linux kernel CREDITS file has an entry mentioning it too: N: Rick Sladkey D: utility hacker: Emacs, NFS server, mount, kmem-ps, UPS debugger, strace, GDB [...]
dfox 2y ago
kvm_getprocs is in userspace library libkvm which abstracts away how that is done. And that library is primary meant for accessing /dev/kmem and crashdumps, with this functionality being bolted onto it (FreeBSD manapage even mentions that as a bug) and it works by examining the symbol table of running kernel and just walking the kernel datastructures. On FreeBSD there seems to be some trick where opening "/dev/null" instead of "/dev/kmem" causes the process "to not access kernel memory directly". Looking at the code it seeems to me that it means that libkvm will really open /dev/null and treat it as if it was /dev/kmem, which raises a question of exactly how that works. [Edit: apparently this works because in case of querying processes of running kernel, the code in kvm_proc.c does not read from the file and instead calls sysctl().]

yjftsjthsd-h 2y ago

The post you're replying to didn't say "on Linux" - IIRC, unix ps worked by reading /dev/kmem or so Edit: My mistake, it was /dev/mem - https://github.com/lsahn-gh/unix-v6/blob/master/source/s2/ps.c#L100 https://github.com/lsahn-gh/unix-v6/blob/master/source/s2/ps...

upon_drumhead 2y ago
Agh, completely fair. The topic was about Linux and I incorrectly presumed that the original comment was made in the same context. My mistake.

donio 2y ago

I remember this too. Very early on there were both proc and a /dev/kmem versions of ps and maybe top too. Yep, found it: https://www.ibiblio.org/pub/historic-linux/ftp-archives/sunsite.unc.edu/Sep-29-1996/system/Status/ps/INDEX.html https://www.ibiblio.org/pub/historic-linux/ftp-archives/suns... And the Linux kernel CREDITS file has an entry mentioning it too: N: Rick Sladkey D: utility hacker: Emacs, NFS server, mount, kmem-ps, UPS debugger, strace, GDB [...]

dfox 2y ago

kvm_getprocs is in userspace library libkvm which abstracts away how that is done. And that library is primary meant for accessing /dev/kmem and crashdumps, with this functionality being bolted onto it (FreeBSD manapage even mentions that as a bug) and it works by examining the symbol table of running kernel and just walking the kernel datastructures. On FreeBSD there seems to be some trick where opening "/dev/null" instead of "/dev/kmem" causes the process "to not access kernel memory directly". Looking at the code it seeems to me that it means that libkvm will really open /dev/null and treat it as if it was /dev/kmem, which raises a question of exactly how that works. [Edit: apparently this works because in case of querying processes of running kernel, the code in kvm_proc.c does not read from the file and instead calls sysctl().]