Date: Wed, 14 Feb 2001 17:32:56 +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: <20010214173256.B1587@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. .. and extending my last email, here's how I see it: sysctl is designed for numerical or binary data return procfs (or any synthetic fs) is designed for text based data return The trouble here that I see is that people are inventing overly-complex methods of representing the data when they could just export it in text format. Yes, I know all about the problems there are with linux's procps/proctop. But in my opinion, I'm quite happy to fix the problems in procfs and attack the speed issues people keep seeing rather than invent an increasingly complex method of exporting data which isn't "right" yet. I am also one of those people who see evilnesses in going take raw data -> generate text -> parse text -> get raw data, but is this really an interface we need blindingly fast? (My 2c, I might run off and commit a proof of concept "stat" file to procfs this week..) 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?20010214173256.B1587>