From owner-cvs-all  Mon Sep 14 07:42:11 1998
Return-Path: <owner-cvs-all>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id HAA13445
          for cvs-all-outgoing; Mon, 14 Sep 1998 07:42:11 -0700 (PDT)
          (envelope-from owner-cvs-all)
Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA13372;
          Mon, 14 Sep 1998 07:41:31 -0700 (PDT)
          (envelope-from peter@netplex.com.au)
Received: from spinner.netplex.com.au (localhost [127.0.0.1])
	by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id VAA10681;
	Mon, 14 Sep 1998 21:46:03 +0800 (WST)
	(envelope-from peter@spinner.netplex.com.au)
Message-Id: <199809141346.VAA10681@spinner.netplex.com.au>
X-Mailer: exmh version 2.0.2 2/24/98
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
cc: Andrzej Bialecki <abial@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG,
        cvs-all@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/i386 machdep.c 
In-reply-to: Your message of "Mon, 14 Sep 1998 14:28:41 +0200."
             <24254.905776121@critter.freebsd.dk> 
Date: Mon, 14 Sep 1998 21:45:58 +0800
From: Peter Wemm <peter@netplex.com.au>
Sender: owner-cvs-all@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Poul-Henning Kamp wrote:
> In message <199809141225.UAA10464@spinner.netplex.com.au>, Peter Wemm writes:
> >Poul-Henning Kamp wrote:
> >> In message <199809141147.EAA18800@freefall.freebsd.org>, Andrzej Bialecki 
    wri
> >    te
> >> s:
> >> >abial       1998/09/14 04:47:41 PDT
> >> >
> >> >  Modified files:
> >> >    sys/i386/i386        machdep.c 
> >> >  Log:
> >> >  This implements retrieving the contents of message buffer via sysctl(3)
> >> >  as "machdep.msgbuf". It's needed in case of using stripped kernels, whe
    re
> >> >  normal dmesg (which has to use kvm) doesn't work.
> >> >  
> >> >  The buffer is unwound, meaning that the data will be linear, possibly
> >> >  with some leading NULLs.
> >> 
> >> Now dmesg should be changed to use this interface, so that one less 
> >> program needs access to /dev/kmem...
> >
> >I've found dmesg's ability to extract the msgbuf from a crashdump to be 
> >invalueable.. ie: "dmesg -N kernel.41 -M vmcore.41".  It would be a shame 
> >to loose this ability without some other replacement.  The same goes for 
> >ps(1).
> 
> I think we should have a crash(8) style tool for this, or maybe a set
> if gdb macros.  
>
> /dev/kmem should die

By all means, yes, it'd be great when/if it goes away, but I doubt that 
gdb macros will ever even remotely fill the hole left.

The main reason why it won't fly is that you need a -g kernel, and people 
generally don't compile -g kernels unless things are getting pretty grim.
gdb is overkill for what is badly needed.

crash(8) would be great, if only it could ever get written. :-)

What I'd suggest is that the most sensible thing would be to have a 
general supporting framework that could allow modules to be linked in to 
extend the command set.  At a minimum, it'll need a pretty complete ps, 
netstat, dmesg, stack traceback, process state dumps, a data examination 
tool, disassembler, and the ability to teach it about new structures.  
Macros and scripting would be really nice.  Savecore could then also do a 
post-crash automatic analysis right next to kernel.x and vmcore.x.

Most of what sysv crash(8) does is display various tables and structures.  
Some way of processing include files and/or stabs output would be really 
nice to shortcut the legwork.

Then, by all means, fry use of libkvm and eventually itself.  I'll be there
to help kill it. :-)

Cheers,
-Peter