console messages and log level

[Andy Whitcroft]

We are now moving into new territory where the kernel is naked in front
of the user for some seconds before xsplash covers its blushes.  The
kernel has traditionally been very chatty and although it has a 'quiet'
mode which we use for normal boots it is still keen to tell us about a
lot of events and errors.

During the lifetime of the kernel it is only this very early phase where
any messages are visible at all.  Once X has started the console is gone,
even 'emergency' messages are only visible via dmesg.  Until recently
usplash was also hiding our messages, again hiding every message level.
Generally in the life the kernel, its idea of importance is ignored, and as
a result not all of its levels are accurate; leading to the issue at hand.

Now we can attempt to fix these messages so they come out at lower levels
(KERN_WARN or lower), indeed we are already seeing requests to quieten
some of these messages.  Typically we do this by dropping the severity of
those messages via a patch, a patch which typically upstream is unlikely
to want and which we will have to carry for the long haul.

Does it really make sense for us to carry a large number of silencer
patches?  I am not convinced.  As we are happy for X to hide all messages
and indeed we added usplash to hide them before X started, perhaps the
sensible thing to do is simply suppress them completely on a regular boot.
The kernel already has a log_level indicating which messages are important
enough to display on the real console and we use this to control verbosity
on boot.

When we look at a normal boot we boot with 'quiet' on the command line.
This lowers the kernels noise level and is also passed to userspace which
again reacts quieting it init.d script logging levels and the like.  If
things fail we normally boot without 'quiet' and we get the full glory
of the kernel output and userspace output too.

To cut to the chase, rather than patching lots of kernel messages to lower
their level might it make just as much sense to lower the level at which
console messages are emitted in the face of the 'queiet' command.  To allow
the kernel to shield itself more heavily.  We could probabally lower the
console level from the default 4 to 1 allowing only emergency messages
to be seen without losing anything in the debug case.  Messages are still
logged to the dmesg and thus the logs, and if booting is broken removing
'quiet' will give us all messages, and indeed log_level=4 will give us
the current behaviour.

In short.  We try very hard in normal running to hide the kernel and are
happy to hide it completly, why is early boot any different.

If you think this makes sens I can spin a patch for testing.

-apw