On Mon, Feb 12, 2001, Robert Watson wrote:
> 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.
.. and extending my last email, here's how I see it:
sysctl is designed for numerical or binary data return
procfs (or any synthetic fs) is designed for text based data return
The trouble here that I see is that people are inventing overly-complex
methods of representing the data when they could just export it in
Yes, I know all about the problems there are with linux's procps/proctop.
But in my opinion, I'm quite happy to fix the problems in procfs and
attack the speed issues people keep seeing rather than invent an
increasingly complex method of exporting data which isn't "right" yet.
I am also one of those people who see evilnesses in going
take raw data -> generate text -> parse text -> get raw data, but
is this really an interface we need blindingly fast?
(My 2c, I might run off and commit a proof of concept "stat" file to
procfs this week..)
Adrian Chadd "Programming is like sex:
<[EMAIL PROTECTED]> One mistake and you have to support for
a lifetime." -- rec.humor.funny
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message