Date: Mon, 16 Jun 1997 17:39:49 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, hasty@rah.star-gate.com, dyson@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Need to rebuild libkvm,ps,w Message-ID: <199706170039.RAA18347@phaeton.artisoft.com> In-Reply-To: <199706170017.JAA13345@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jun 17, 97 09:47:00 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Actually, isn't it really the memory image arguments to ps/w/et. al. > > that cause the problem? We could go to /proc tomorrow if /proc > > were mandatory and we didn't care about ps'ing crash dumps (doing > > that sems to me to be the job of the kernel debugger, anyway). > > Argh. I keep forgetting that case 8(. Who does still use ps on crash > dumps? Is it useful in that form? I found it useful; I'm sure many people would say that it was. Mostly because there is no good "crash" program with an intrinsic "ps" command to replace it. As an alternative to "/proc", it should be possible to put a "shared library" in a seperate object section in a kernel, and have *it* know about the kernel data format. This would be transported with the kernel, and so available to the users trying to debug a crash-dump. Be default, the kernel section would not be loaded by the kernel loader (section name "ABI"?), and used by the tools with no direct knowledge of the kernel data internal itself. Functionally, this identical to a procesural interface instead of a data interface, which is the main issue that needs addressing. Of course, it requires going to ELF, since a.out can't do sections, a requirement of the design, but that's probably less eventual work than crafting a good "crash" program and a full-on "/proc" interface (which, unless adulterated, isn't much good for anything but processes). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706170039.RAA18347>