From owner-freebsd-arch@FreeBSD.ORG Sun May 28 07:39:07 2006 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7DE516A935 for ; Sun, 28 May 2006 07:22:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62FFE43D48 for ; Sun, 28 May 2006 07:22:35 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k4S7JTg9082830; Sun, 28 May 2006 01:19:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 28 May 2006 01:19:32 -0600 (MDT) Message-Id: <20060528.011932.1220016372.imp@bsdimp.com> To: peterjeremy@optushome.com.au From: "M. Warner Losh" 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> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, julian@elischer.org Subject: Re: A sort of plan for consoles in FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2006 07:39:22 -0000 In message: <20060528062113.GN744@turion.vk2pj.dyndns.org> Peter Jeremy 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