Date: Sat, 26 Feb 2000 10:34:52 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Peter Wemm <peter@netplex.com.au> Cc: "Jordan K. Hubbard" <jkh@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern init_main.c Message-ID: <Pine.NEB.3.96L.1000226102946.633C-100000@fledge.watson.org> In-Reply-To: <20000226152623.E33A91CE3@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 26 Feb 2000, Peter Wemm wrote: > "Jordan K. Hubbard" wrote: > > > The dmesg buffer is a lot bigger than the screen scrollback buffer. It > > > would still be useful to see the output of dmesg. > > > > Understood, but couldn't you also just look at /var/run/dmesg.boot > > yourself if you're at the stage where you can run /stand/sysinstall > > interactively? :-) > > I thought we were talking about accessing dmesg at initial install time.. > ie: after sysinstall has cleared the scrollback buffer on ttyv0. It's a > royal pain in the backside to try and figure out if all the devices probed > correctly. I've lost count of the times I've got most of the way through > configuring an install and then discovered the ethernet card was on the > wrong port and didn't get probed and then had to abandon it and start > again. I'd love to be able to check probes etc before getting into a heavy > custom install session. I think this actually points to two needs-- 1) Make the results of the hardware probe process more accessible during the install by providing a dmesg viewing capability (presumably which dumps the contents of the appopriate sysctl and post-processing into a dialog scrollable file viewer), so that the limits of the scroll-back buffer (especially in verbose mode) don't prevent installers from seeing what happened 2) Make the current hardware configuration more accessible -- perhaps an lsdev that uses sysctls to retrieve hardware configuration information. As nice as dmesg is for retrieving hardware probe results, wouldn't you rather be able to unifirmly retrieve ports, IRQs, memory ranges via a consistent sysctl interface? Each bus or device introduced (and successfully probed) could instantiate a sysctl node off of the dev. sysctl root, with the node in question named using the device name and number, and then a series of sub-nodes for irq(s), port (ranges), etc. Clearly #2 is a more long-term thing, but I've often been jealous of Windows having a device manager in the control panel that (attempts) to match up with the current hardware configuration probed by the OS. dmesg.boot isn't an alternative to a structures driver interogation mechanism. (patches not attached) Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000226102946.633C-100000>