From owner-freebsd-hackers Mon Sep 30 10:44:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA16015 for hackers-outgoing; Mon, 30 Sep 1996 10:44:19 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA15946 for ; Mon, 30 Sep 1996 10:44:09 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA06193; Mon, 30 Sep 1996 10:42:10 -0700 From: Terry Lambert Message-Id: <199609301742.KAA06193@phaeton.artisoft.com> Subject: Re: PS broke again -- what has to be rebuilt to stop this? To: karl@Mcs.Net (Karl Denninger) Date: Mon, 30 Sep 1996 10:42:10 -0700 (MST) Cc: chuckr@glue.umd.edu, karl@Mcs.Net, hackers@FreeBSD.ORG In-Reply-To: <199609292014.PAA12032@Jupiter.Mcs.Net> from "Karl Denninger" at Sep 29, 96 03:14:11 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > No, I well understand that -CURRENT changes. > > That's the point of it being "current". > > However, if I want to run a new kernel, I shouldn't have to rebuild half > of the system utilities! > > I can understand if kernel structures change. But FreeBSD *BADLY* needs a > reasonable way to avoid this kind of problem. There IS a fix for this -- > reasonably-version the shared libraries (ie: libc.so.3.0.2, etc) and embed > the preferred library name in the executable being built. > > Now if you change the kernel structures and the "ps/w/everything-that-reads > structures" has to change, you can update libkvm.so.x.y.z *ONLY* and get a > new version number for it -- and the new executables you build for it will > know what they want. > > "make install" on an NFS mounted obj and src tree is unacceptable for a > number of reasons -- not the least of which is that all of the SUID security > fixes that I have done get UNDONE when you do this! Personally, I've always thought that the structure should be absracted from the reporting -- specifically, ps should use procfs. The problem with this approach is that ps then fails to operate on crashdumps, which are by definition passive data. If this was an acceptable outcome (one could argue that a functioning kdb should be capable of doing a ps, since a panic could leave you at a debug prompt, and you may still want to ps before rebooting), then moving to an abstracted interface would permanently solve the problem for all utilities that otherwise read kvm. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.