From owner-svn-src-head@FreeBSD.ORG Fri Feb 17 19:20:39 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FDCF106566B; Fri, 17 Feb 2012 19:20:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id AD9D88FC0C; Fri, 17 Feb 2012 19:20:38 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1HJKYun011011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Feb 2012 06:20:36 +1100 Date: Sat, 18 Feb 2012 06:20:34 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Marcel Moolenaar In-Reply-To: <2CDFAEC9-D57A-4513-96D1-8A78D27E8696@xcllnt.net> Message-ID: <20120218050858.Q4138@besplex.bde.org> References: <201202160511.q1G5BZNk099785@svn.freebsd.org> <20120216181210.K1423@besplex.bde.org> <4F3CC40D.4000307@freebsd.org> <4F3CC5C4.7020501@FreeBSD.org> <4F3CC8A5.3030107@FreeBSD.org> <20120216174758.GA64180@nargothrond.kdm.org> <20120217053341.R1256@besplex.bde.org> <20120217000846.GA7641@nargothrond.kdm.org> <4F3D9D03.6020507@FreeBSD.org> <9CB7ECE8-FF10-43BE-9EBD-16953BE3B193@xcllnt.net> <20120217191017.U1871@besplex.bde.org> <2CDFAEC9-D57A-4513-96D1-8A78D27E8696@xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 17 Feb 2012 19:25:50 +0000 Cc: marcel@freebsd.org, Eitan Adler , svn-src-all@freebsd.org, "Kenneth D. Merry" , Andriy Gapon , src-committers@freebsd.org, Bruce Evans , svn-src-head@freebsd.org, Julian Elischer Subject: Re: svn commit: r231814 - in head/sys: kern sys X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 19:20:39 -0000 On Fri, 17 Feb 2012, Marcel Moolenaar wrote: > On Feb 17, 2012, at 4:13 AM, Bruce Evans wrote: > >> On Thu, 16 Feb 2012, Marcel Moolenaar wrote: >> >>> I think we should lift above the immediate problem and allow for >>> single- and multi-line messages that are atomically appended to >>> the message buffer. Console output and propagation of messages >>> outside of the kernel should all come out of the message buffer >>> and preserving the atomicity of the messages. >> >> This is just wrong for (low-level) console messages. > > I think it actually is the right approach in that the low-level > console stops being this pivotal component that introduces > limitations for no good reason. I like it limiting bloat. But if you really want, you can have no limit on messages that don't go to the console imposed by messages that do go to the console. > We need "quiet" boots, but we > also want to have boot messages available somewhere for post > mortems. Decoupling the generation and holding/storage of Well, I want noisy boots. > messages from what you can subsequently do with them, like > displaying them, is a good thing. The decoupling allows us > to generate and store messages in the most stringent cases, > and it allows us to filter based on preference or condition. If many cared about this, then they would have used log(9) and perhaps added more priorities to it instead of almost always using printf(). In the $(find /sys -name *.c) now, there are about 29457 lines matching 'printf(' (this will find slightly different functions line sprintf() and device_printf()) and 1686 matching 'log('. printf() is just too convenient, although the only inconvenience for using arg of log() is its extra priority arg which helps filtering. I thought that log had a LOG_PRINTF psuedo-prioriy to make it go to the console, but I can never remember what its priorities are, and looking them up shows that LOG_PRINTF is only used in removed disk code, and looking at the source code shows that log() only goes to the console when klog is not open. The latter is as it should be -- don't spam the console with kernel printfs (which also go to klog, but with an uncontrollable priority), but let syslog filter them. > It's not that hard to print messages that relates to errors > only when you have priorities or facilities or other kinds > of augmentation that help us raise awareness of the things > FreeBSD users/operators need to be aware of. > > I belief the notion of a low-level console is arcane and > antiquated. Every "output" channel that can be monitored by > humans should have the possibility of being human friendly, > where human friendly is defined, for the most part, by the > the human monitoring the channel and not by us. Console printfs is mainly for people debugging kernels. One per day is acceptable for other purposes. > For example: I dislike our boot messages, because it's noise > to me 99.99% of the time. If I'm waiting for FreeBSD to boot > and monitor the console, I'd rather stare at the logo and a > twiddle. If I see a lot of messages scrolling by fast, I look > away (preferably at a photo of a white tropical beach, the > sea and a few palm trees). I really like them. The scroll fast by fast enough that they are easy to ignore. If I want to see them later, then scroll-lock mode is usable despite its bugs. If you don't like them, then turn them off by booting with RB_MUTE. I've never tried this of course. As a kernel hacker, you can see the message buffer using ddb or maybe gdb even if the boot fails. Bruce