From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 22:57:17 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 783E816A474 for ; Wed, 19 Sep 2007 22:57:17 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 3777613C461 for ; Wed, 19 Sep 2007 22:57:17 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 19 Sep 2007 15:51:54 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id l8JMvGNu085615; Wed, 19 Sep 2007 15:57:16 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id l8JMvGAQ085614; Wed, 19 Sep 2007 15:57:16 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200709192257.l8JMvGAQ085614@ambrisko.com> In-Reply-To: <96A863DB-3C0B-4AD0-B0A1-3C0A89B42C75@mac.com> To: Marcel Moolenaar Date: Wed, 19 Sep 2007 15:57:16 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() 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: Wed, 19 Sep 2007 22:57:17 -0000 Marcel Moolenaar writes: | With FreeBSD being used in various situations, including the embedded | space, there seems to be an increasing need to have fine-grained | control over what the kernel prints to the console during boot as well | as during normal operation. It is my believe at least that the all or | nothing approach that we have now is inadequate. | | With this email I'd like to start a discussion in an attempt to get | some feel for what is possible and/or acceptable as well as get more | information about the situations where the current behaviour of | FreeBSD had to be changed (or people wished it would change). | | We currently have standard, verbose and mute. Standard is really | already too verbose from a regular user (i.e. non-developer) | point of view. Mute is really not adequate, because you may want | to print at least the copyright notice or provide a couple of | lines of critical information even when you don't wont to see | anything else. | | On top of that, if we shift our thinking towards the theoretical, | futuristical and/or luxurious then we may be faced with multiple | output devices, such as a small LCD, onto which we want to print | some status information. With multiple output devices we may want | to channel different kinds of messages to different devices. | | As a first stab, I'm thinking that if we amend the printf()s with | a syslog-type facility and/or level, we may achieve just that. | Replacing printf with klog() and change the printf implementation | to be in terms of a klog call with an as of yet unspecified level | and/or facility would help migrate from one system to another. | | What do people think of such an ability? | | Have people implemented something similar as part of their own | FreeBSD-based solutions? | | If we have the ability to suppress certain kinds of output, | do we still want save the supressed output somewhere and do | we want to be able to have fine-grained control over that too? As a person that has done a bunch of appliance work I wouldn't support this. What I/other companies have done is just to mute the console and decide on what and when messages of our own should be displayed. Okay, we do hacks so if the machine panic's it will un-mute the console and dump it to a serial port. Also it will dump a smaller sub-set to ipmi system event logs. Note this does require a bit of code change since the kernel needs to flip the consmute back and forth so I made a function call deal with it. Also serial gizmo's etc. can require a non-standard communication method so doing a "kernel printf" might not work with just ascii text. I've also done this for BIOSs which we need to display codes to an LCD so we can display bad memory errors etc. What generic mechanism you proprose wouldn't meet everyone's needs so then it is easier for them to just implement their needs. It isn't that hard and even with a muted console you get dmesg/console.log output etc. (okay that might be with my patched version). Then you can parse the logs and spit them out. You can even make syslog run the parser. I think we need to keep FreeBSD simple and selecting a serial, vga or muted console is fine. I also have a patch so that you can tell the kernel it is a muted, serial console since that info is lost from the loader -> kernel since it sets console= so if console=nullconsole then the kernel doesn't know if the serial console was muted or not. So I made a new altconsole variable so then we set console=nullconsole altconsole=comconsole so then kernel knows what console is muted. Other variables/schemes could be used but this works for me for now. It would be nice to have both a vga and serial console :-) There used to be "dual" console at the boot blocks level. Doug A.