On Thu, Jan 31, 2019 at 6:06 AM Ed Maste <[email protected]> wrote: > > On Wed, 30 Jan 2019 at 18:58, Rob Landley <[email protected]> wrote: > > > > The bigger problem for BSD/macos is ps.c parses /proc/$PID/stat to get its > > process information, and I don't think BSD even has that concept? > > We do have a procfs, but its use is discouraged and is not compatible > with the Linux procfs. We do have a linprocfs for the Linux emulation > layer, but it's not mounted in a FreeBSD tree. > > > No idea where > > BSD or MacOS versions of ps get this sort of data. (Bell Labs unix read > > /dev/mem > > and parsed the in-kernel process table structures. No really! > > Yep, there are vestiges of this history in FreeBSD still, and I > believe the FreeBSD lsof port still works this way. > > On FreeBSD ps links against libkvm and uses kvm_getprocs, from the man page: > > struct kinfo_proc * > kvm_getprocs(kvm_t *kd, int op, int arg, int *cnt); > > The kvm_getprocs() function returns a (sub-)set of active processes in > the kernel indicated by kd. The op and arg arguments constitute a > predicate which limits the set of processes returned. The value of op > describes the filtering predicate as follows: > > KERN_PROC_ALL all processes and kernel visible threads > KERN_PROC_PROC all processes, without threads > KERN_PROC_PID processes with process ID arg > KERN_PROC_PGRP processes with process group arg > KERN_PROC_SESSION processes with session arg > KERN_PROC_TTY processes with TTY arg > KERN_PROC_UID processes with effective user ID arg > KERN_PROC_RUID processes with real user ID arg > KERN_PROC_INC_THREAD modifier to return all kernel visible threads > when filtering by process ID, process group, > TTY, user ID, and real user ID > > The man page also includes a BUGS section that states "These routines > do not belong in the kvm interface" but they presumably will never > move. > > Under the hood kvm_getprocs uses the sysctl interface, > kern.proc.<op>.<pid>. Source is here: > https://reviews.freebsd.org/source/src/browse/head/lib/libkvm/kvm_proc.c$491 > > I haven't looked at Darwin, but I suspect it uses the same interface. > Linking against libkvm on *BSD seems reasonable. > > > In practice, the dirtree infrastructure that finds the processes > > (lib/dirtree.c) > > is recursive directory descent plumbing populating a tree of struct dirtree > > * > > structures for each entry and calling a callback function to filter and/or > > act > > upon them. Which means A) it assumes it's reading a filesystem to populate, > > B) > > our get_ps() is a callback function that knows about the /proc layout. > > There's > > also a get_threads() shim that descends an extra level for Linux's weird > > thread > > layout (and then calls get_ps() to do the reading once it's identified the > > next > > directory with something interesting). > > For us including or excluding threads is just a flag to kvm_getprocs. > > If it simplifies things leaving get_ps as a callback seems fine, > although replacing the dirtree search means there's probably a fair > bit that needs to be done differently. In any case for me the more > system-specific utilities are the lowest priority; the pure > text-processing and basic filesystem utilities are more interesting > initially.
same here: it's stuff like md5sum and grep and realpath and sed where the AOSP build has trouble because macOS is just different enough to cause trouble. (there _are_ rare references to things like ps, but only for diagnostics if something went horribly wrong.) > _______________________________________________ > Toybox mailing list > [email protected] > http://lists.landley.net/listinfo.cgi/toybox-landley.net _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
