Re: Reducing noise in dmesg output

On Wed, 2 Sep 2009, Tim Kientzle wrote:

>>> FreeBSD has historically been producing very limited output on dmesg. 
>>> Linux is very noisy (ever noticed the copyright notices right in the 
>>> middle of your list of PCI devices?). Even they have decided that they 
>>> should hide this behind coloured 'ok/failed' texts in some distributions.
>> 
>> I think this speaks more towards needing something between "Very Quiet" and 
>> "Give me everything every developer has ever wanted to know enough to 
>> include a print for it."
>
> Other possibilities:
>
> * Provide a per-driver control to determine verbosity.  That would make it 
> easier for developers who really do want to see "everything there is to know 
> in my part of the world".
>
> * Put more information into the kernel buffers (and from there into dmesg) 
> and less on the screen.  That would reduce visible boot verbosity while 
> retaining the post-hoc debugging value of dmesg(1).

It's clear that part of the problem we're dealing with here is that dmesg 
remains the authoritative source for certain kinds of data that really should 
be in a machine-readable/reportable format.  devinfo(8) captures some of this, 
but can't, for example, cleanly represent an IRQ being shared by multiple 
devices, and doesn't capture a lot of the device-driver specific data that 
appears in dmesg.

dmesg is a useful log of events, and I'm not saying we should omit information 
there, but when inspecting the current state of the system, the kernel has a 
lot of information and it would be nice if more of it were accessible in 
userspace.

To my mind, the main reason to look at dmesg should be to find out about 
*failed* device attaches, where there most likely won't be persisting state in 
the kernel, but the debugging information is invaluable.

Robert N M Watson
Computer Laboratory
University of Cambridge