Replacing/enhancing kernel printf()

[Doug Ambrisko]

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.