Date: Sun, 28 May 2006 01:19:32 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: peterjeremy@optushome.com.au Cc: arch@FreeBSD.org, julian@elischer.org Subject: Re: A sort of plan for consoles in FreeBSD Message-ID: <20060528.011932.1220016372.imp@bsdimp.com> In-Reply-To: <20060528062113.GN744@turion.vk2pj.dyndns.org> References: <16029.1148764704@critter.freebsd.dk> <44793146.6070200@elischer.org> <20060528062113.GN744@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20060528062113.GN744@turion.vk2pj.dyndns.org>
Peter Jeremy <peterjeremy@optushome.com.au> writes:
: 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.
There's special code in the kernel that knows how to talk to the
hardware before it has been fully probed. All the early boot messages
are printed out using this low-level console. This is #2 in phk's
world. Some platforms tie this low-level console to the firmware from
#1, but i386, amd64, pc98, ia64 and arm (maybe others too) all go
directly to real hardware using the low-level console routines.
: >>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.
LOG_CONS happens only when it can't sent the message to syslogd(8).
LOG_PERROR will also print it on stderr. LOG_CONS would then
degenerate into LOG_PERROR. If the data can't already be sent to
syslogd(8) by userland, I'm not so sure that the kernel would have
better luck.
: I thought dump(8) did but it doesn't appear to any longer.
dump used to, but now uses wall.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060528.011932.1220016372.imp>