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

[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 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

Reply via email to