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 cvs-all" 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>