Date: Mon, 30 Sep 1996 12:45:35 -0500 (CDT) From: Karl Denninger <karl@Mcs.Net> To: terry@lambert.org (Terry Lambert) Cc: karl@Mcs.Net, chuckr@glue.umd.edu, hackers@FreeBSD.ORG Subject: Re: PS broke again -- what has to be rebuilt to stop this? Message-ID: <199609301745.MAA06478@Jupiter.Mcs.Net> In-Reply-To: <199609301742.KAA06193@phaeton.artisoft.com> from "Terry Lambert" at Sep 30, 96 10:42:10 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 I absolutely agree here. A functioning kdb should be able to do a "ps" on the crash dump, which is the point of being able to back-trace, yes? I would argue that the system command "ps" is by *definition* a working-set tool *only*. If you want one which runs on crash dumps, then let's have one which does that. If we run through procfs then the problem gets solved -- and frankly, I like that outcome -- a lot. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609301745.MAA06478>