libprocstat(3): retrieve process command line args and environment

[John Baldwin]

On Friday, January 25, 2013 1:37:45 pm Robert N. M. Watson wrote:
> 
> On 24 Jan 2013, at 16:20, John Baldwin wrote:
> 
> >>> Hmm, are you going to rewrite ps(1) to use libprocstat?  Or rather, is 
that a
> >>> goal someday?  That is one current consumer of kvm_getargv/envv.  That 
might
> >>> be fine if we want to make more tools use libprocstat instead of using 
libkvm
> >>> directly.
> >> 
> >> I didn't have any plans for ps(1) :-) That is why I wrote about "new
> >> code". But if you think it is good to do I might look at it one day...
> > 
> > I'm mostly hoping Robert chimes in to see if that was his intention for
> > libprocstat. :)  If we can ultimately replace all uses of kvm_get*v() with
> > calls to procstat_get*v*() then I'm fine with some code duplication in the
> > interim.
> 
> 
> Originally there was just proctstat(1), but it made sense to begin re-
encapsulating it in a libprocstat(3) because the code there is potentially 
extremely reusable. This conflicts a bit with libkvm(3), which mysteriously 
knows about sysctlbyname(3) despite a name suggesting otherwise. You can 
imagine various approaches to fixing this, but indeed, making libprocstat(3) 
the first-class citizen and preferring it for both kvm and sysctl methods 
sounds like the way to go. I actually want to make libprocstat also support 
snmp, but I've never actually found the time to investigate doing that. One of 
my main unmet goals for procstat(1) was to introduce an extremely machine-
readable output format for it -- e.g., something XML-based or similar. I'd 
still love to see that happen.

BTW, one off-ball thought I have is that I would like to have a mode where 
libprocstat operates on a core file (of a process, not a kernel crash dump), 
so it could list the threads from a core dump, and possibly file descriptor 
info (if PR kern/173723 is implemented).

We certainly could have a 'raw' mode where it spat out name: value or XML
of the entire kinfo_proc perhaps.

-- 
John Baldwin