Darren Reed wrote:

> Just for reference, I'd like to mention the pstat(2) interface on HP-UX.

From the message I sent in the sysinfo(2) thread:

sb> I was thinking about something similar to this just this week, having
sb> been exposed to HP/UX for the first time and having to get some info
sb> about a process from a user land program.  The pstat*() calls that take
sb> the (buffer, elem_len, num_elem [, index]) arguments seem to be a good
sb> way of fixing the 'proc size mismatch' problems we have.

:-)

> It is similar to sysctl() but does not extend itself to networking, etc.
> Through their interface, they return structures which are not the same
> as those used by the kernel for holding process info, etc.  Notably, the
> structures returned do not contain pointers of any sort - information only!
> Obviously there are issues here when it comes to getting things out of
> crash dumps, but an appropriate library interface can deal with that.
> So where am I going...
> 
> I'm not sure if I've seen it mentioned already, but maybe ps should be
> using a sysctl() which return a block of such sanitized data.  In that
> way, it is not nearly as likely that arbitrary changes to proc or user
> are likely to effect the interface ps uses.

This is pretty much what I'm proposing.  The current KERN_PROC returns
a 'struct kinfo_proc' which includes a struct proc plus some other bits
and pieces.  The 'struct kinfo_proc2' I'm proposing returns "sanitized
data" (to use your words), even more so after Eric's suggestions to
handle NETBSD_COMPAT32.

> As far as debugging crash dumps/running kernels goes, if your tools
> are't tuned to the particular version in question then you've got to
> ask yourself whether you are doing yourself a service or dis-service.

True.  My motivation for adding crash dump support to kvm_getproc2() is
so that ps(1) and friends can use the same interface on a running or
dead kernel.  That you could run an out-of-date ps on a new kernel is
strictly a feature :-)

Simon.