Date: Wed, 19 Sep 2007 15:57:16 -0700 (PDT) From: Doug Ambrisko <ambrisko@ambrisko.com> To: Marcel Moolenaar <xcllnt@mac.com> Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() Message-ID: <200709192257.l8JMvGAQ085614@ambrisko.com> In-Reply-To: <96A863DB-3C0B-4AD0-B0A1-3C0A89B42C75@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=<splat> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709192257.l8JMvGAQ085614>