Date: Mon, 12 Feb 2001 09:43:24 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Dag-Erling Smorgrav <des@ofug.org> Cc: 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: <Pine.NEB.3.96L.1010212093948.87908B-100000@fledge.watson.org> In-Reply-To: <xzpbss8c80s.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services 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?Pine.NEB.3.96L.1010212093948.87908B-100000>