Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Feb 2001 17:19:30 +0100
From:      Adrian Chadd <adrian@FreeBSD.ORG>
To:        Robert Watson <rwatson@FreeBSD.ORG>
Cc:        Dag-Erling Smorgrav <des@ofug.org>, Jake Burkholder <jburkholder0829@home.com>, freebsd-current@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c  src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s  trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c  kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
Message-ID:  <20010214171930.A1587@roaming.cacheboy.net>
In-Reply-To: <Pine.NEB.3.96L.1010212093948.87908B-100000@fledge.watson.org>; from rwatson@FreeBSD.ORG on Mon, Feb 12, 2001 at 09:43:24AM -0500
References:  <xzpbss8c80s.fsf@flood.ping.uio.no> <Pine.NEB.3.96L.1010212093948.87908B-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 12, 2001, Robert Watson wrote:
> 
> On 12 Feb 2001, Dag-Erling Smorgrav wrote:
> 
> > Jake Burkholder <jburkholder0829@home.com> 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:
<adrian@freebsd.org>		   One mistake and you have to support for
				    a lifetime." -- rec.humor.funny



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010214171930.A1587>