On 12 Feb 2001, Dag-Erling Smorgrav wrote:

> Jake Burkholder <[EMAIL PROTECTED]> writes:
> > As I mentioned in the commit message, this changes the size and layout
> > of struct kinfo_proc, so you'll have to recompile libkvm-using programs.
> I thought the whole point with kinfo_proc was to avoid this kind of
> situation... 

It seems to me that kinfo_proc is the wrong solution to a real problem.

John Baldwin and I briefly discussed, online, an alternative solution that
breaks out the per-process information into a series of sysctl's.  This
costs you more in terms of number of calls to retrieve the information, as
well as introducing non-atomicity that might need to be addressed, but
allows you to maintain compatibility in many more situations.  It removes
struct ordering constraints, allows you to happily handle the addition of
new fields, and when a field is removed or changes size, you know which
field it is, and your ability to look at other fields is not impacted. 
Another global sysctl could maintain a list of relevant fields, so you
could even imagine a process browser that was extensible (especially when
using base types for the fields, such as int).  kinfo_proc addresses the
issue that the kernel and userland concepts of a proc diverge due to the
introduction of kernel-only fields, but doesn't really address issues such
as ordered elements of the structure changing size. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]      NAI Labs, Safeport Network Services

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to