Replacing/enhancing kernel printf()

Marcel Moolenaar xcllnt at
Thu Sep 20 14:18:02 PDT 2007

On Sep 19, 2007, at 3:57 PM, Doug Ambrisko wrote:

> 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.

I've read this over a couple of times and it still strikes
me as an odd statement. What I posed for discussion is
exactly what you've done (or had to do) and yet you don't
support it.

> What generic mechanism you proprose wouldn't meet everyone's
> needs so then it is easier for them to just implement their
> needs.

I didn't propose anything yet. I merely stated an example.
The intend is to find out if a generic method exists that
works for everyone, and if not, to what extend we can make
it flexible and generic without trying to meet everyone's

You advocate that people implement (and re-implement) what
they need based on the status quo. I don't see how it is
impossible to change the status quo and still have people
implement (and re-implement) what they need, provided we
don't make things impossible. In other words, if some
future infrastructure supports the status quo, no matter
how complex we make it otherwise, then your needs are met
aren't they?

> I think we need to keep FreeBSD simple and selecting a
> serial, vga or muted console is fine.

No, I don't think it is. For example, we already support
using all devices as console with the -D option. With EFI,
where multiple consoles can be configured this would be
a useful feature so that the OS outputs to the same devices
the firmware does.
But what about our firewire console or serial over USB?
And what about headless setups when there's only a LCD?

What I'm trying to say is that a PC-centric point of
view as a basis for a design is too limited. You already
acknowledge that, because you had to make changes and hack
the code to make it fit your needs. So, things aren't
fine according to my interpretation.

>   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.

This is very PC oriented. These variables mean nothing on
sparc64, powerpc or ia64 for example. There's nothing I
can do with what you say here.

Marcel Moolenaar
xcllnt at

More information about the freebsd-arch mailing list