Reducing noise in dmesg output
Robert Watson
rwatson at FreeBSD.org
Thu Sep 3 09:38:21 UTC 2009
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
More information about the freebsd-current
mailing list