From owner-freebsd-current Wed Feb 14 10: 9:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from roaming.cacheboy.net (node16292.a2000.nl [24.132.98.146]) by hub.freebsd.org (Postfix) with ESMTP id 4C0CF37B491; Wed, 14 Feb 2001 10:09:33 -0800 (PST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f1EGJoh01636; Wed, 14 Feb 2001 17:19:50 +0100 (CET) (envelope-from adrian) Date: Wed, 14 Feb 2001 17:19:30 +0100 From: Adrian Chadd To: Robert Watson Cc: Dag-Erling Smorgrav , 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 ... Message-ID: <20010214171930.A1587@roaming.cacheboy.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.ORG on Mon, Feb 12, 2001 at 09:43:24AM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 12, 2001, Robert Watson wrote: > > 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. *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: 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