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.
*sigh* now, if we had per-file open vnode[1] support, I could quite happily
solve this by fixing procfs, but people view procfs as bad for some
reason.
[1] Ignore my vagueness in terms here - the general request is to have
some form of state mapped back to an open file from the VNOPS. This
way at VOP_OPEN() I can populate the file data with some proc info,
and then VOP_READ/VOP_WRITE just read from this, rather than the
evilness (and non-atomic) way they work right now[2].
[2] PLEASE could someone do this or give me some hints? I don't have the
time to do it atm.
Adrian
--
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
