Re: dmesg verbosity [was Re: AGP bogosities]

From: Pavel Machek
Date: Mon Mar 14 2005 - 12:33:50 EST


Hi!

> > We already have the 'quiet' option, but even so, I think the kernel is *way*
> > too verbose. Someone needs to make a personal crusade out of removing
> > unneeded and unjustified printks from the kernel before it really gets better
> > though...
>
> The thing is, this comes up every once in a while (pretty often,
> actually), but the bulk of those messages _do_ end up being useful. For
> certain classes of bugs, I almost invariably ask for the bootup messages:
> the PCI interrupt routing printou stuff is absolutely invaluable.
>
> In fact, even the ones that have no "information" end up often being a big
> clue about where the hang happened.

Problem is that by now we have so much information that valuable
scrolls up. Users start to missing trace dumps in bootup phase because
it just scrolls away too quickly.

I know that "no information" messages can be valuable, but they make
messages with usefull information less likely to be noticed. And
people start doing ugly stuff like

*** This is really
*** important message

when they want their messages to be actually seen. Perhaps we should
reduce ammount of that "no information" messages? I particulary hate
"XXX driver registered" even when that driver has no hardware. Kernel
is quite unlikely to hang at that point.

> And those occasional people are often not going to eb very good at
> reporting bugs. If they don't see anything happening, they'll just give up
> rather than bother to report it. So I do think we want the fairly verbose
> thing enabled by default. You can then hide it with the graphical bootup
> for "most people".

Does it mean that fbsplash done right would be ok for mainline? ;-).

Pavel

--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/