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

[Stanislav Sedov]

On Fri, 25 Jan 2013 15:31:43 -0500
John Baldwin <jhb at freebsd.org> mentioned:

> 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).
> 

That's actually a good idea.  I was thinking about the same for some time.
AFAIK Solaris' pfiles can do that, and maybe some other tools as well.
I have not had time to look into yet, though.

-- 
Stanislav Sedov
ST4096-RIPE

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments