Date: Sun, 28 May 2006 16:21:13 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org Subject: Re: A sort of plan for consoles in FreeBSD Message-ID: <20060528062113.GN744@turion.vk2pj.dyndns.org> In-Reply-To: <44793146.6070200@elischer.org> References: <16029.1148764704@critter.freebsd.dk> <44793146.6070200@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2006-May-27 22:12:38 -0700, Julian Elischer wrote: >Poul-Henning Kamp wrote: >>We have four concepts of "console" in FreeBSD: >> >>1. Whatever boot0/boot1/boot2/loader uses >> Accessed from/via native boot/firmware environment > >#1 is sort of independent as it stops being used at the moment FreeBSd >starts. Last time I checked, the copyright notice and some of the early kernel probe output came via the native firmware (at least on some architectures). There's a bit of a Catch-22 because the kernel wants to report output before it's got far enough through the device probe sequence to be able to talk to the hardware making up the console. >>4. The /dev/console device in multi-user mode. >> Emergency output device for critical messages. > >but, emergency messages from where? You've coverred the ones I care about >above. syslog(3) LOG_CONS immediately comes to mind. A quick check of the source shows that ps(1), init(8), rpc.ypxfrd(8), bits of the lp subsystem as well as thread library's initialisation code can also write to /dev/console. I thought dump(8) did but it doesn't appear to any longer. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060528062113.GN744>