Date: Mon, 14 Sep 1998 14:28:41 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Peter Wemm <peter@netplex.com.au> Cc: Andrzej Bialecki <abial@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/i386 machdep.c Message-ID: <24254.905776121@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 14 Sep 1998 20:25:11 %2B0800." <199809141225.UAA10464@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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, where >> > 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 -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24254.905776121>