From owner-cvs-all Mon Feb 12 6:43:38 2001 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id F20BB37B401; Mon, 12 Feb 2001 06:43:30 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1CEhOh88266; Mon, 12 Feb 2001 09:43:24 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 12 Feb 2001 09:43:24 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dag-Erling Smorgrav Cc: Jake Burkholder , 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 ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 12 Feb 2001, Dag-Erling Smorgrav wrote: > Jake Burkholder 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 cvs-all" in the body of the message