From owner-freebsd-current Mon Jun 16 17:49:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA11864 for current-outgoing; Mon, 16 Jun 1997 17:49:13 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA11853; Mon, 16 Jun 1997 17:49:07 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA18347; Mon, 16 Jun 1997 17:39:49 -0700 From: Terry Lambert Message-Id: <199706170039.RAA18347@phaeton.artisoft.com> Subject: Re: Need to rebuild libkvm,ps,w To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 16 Jun 1997 17:39:49 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, hasty@rah.star-gate.com, dyson@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199706170017.JAA13345@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jun 17, 97 09:47:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 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.