Slashdot Mirror
Linus Says No To Annoying Boot Messages
Pants Ripper writes: "In a victory for all Linux users, Linus Torvalds declared jihad
on annoying 'informational' kernel boot messages. I'm sure we'll all miss the inspirational 'spewtron driver 0.09 installed (C)2000 by Wardwick Extrusion' messages in our dmesgs." I've always thought those messages looked pretty interestingly verbose, but people want pretty boot-ups. And this Linus guy seems to know a lot about this "Lee-nuks," too.
FreeBSD has an option (although it is disabled by default.) to display a boot screen (similar to windows). IIRC, the boot screen can be dumped for the regular boot message by a flag to the loader, or by simply pressing escape during the boot (unless your error is: atkbd0: Error failed to initalize keyboard...
Really, what Linus seems to be annoyed at here are the excessivly verbose messages that some drivers like to print out (like I need to see the algorigthm benchmark each time I boot) that might drown out an important message by scrolling it off of the screen before you see it (although it should still be available through dmesg, just like the FreeBSD boot messages are still are even when you have the "graphical" boot.). The Linux boot sequence is getting a bit heavy on the pointless informational messages these days, so a bit of a pruning won't hurt too much.
Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.
I read the internet for the articles.
Attention, We-Want-Linux-On-The-Desktop crowd: Support this and help out, it is a big step in the right direction. To a consumer, diagnostic messages are confusing and pointless. Admit that Apple did something right, for once (interpret that as you will): the Mac OS, up to and including X, will never show cryptic messages or break out of the GUI unless you give it a direct order to do so (launch Terminal or Console, hold down key sequences during boot) or a fatal error occurs. This is a good thing, it makes the experience seamless and friendly. Remember that consumers don't care about what drivers got loaded when (and isn't improving the drivers themselves a much more important goal than improving the error messages?) and similar arcane knowledge of the computer's internals, and saying "learn it anyway because it's good for you" will not win you any friends or customers.
--
Care about electronic freedom? Consider donating to the EFF!
Dynamic allocation isn't necessarily safe in all the places printk() can be (is) used.
... what happens if the printk() happens to be reporting something due to VM exhaustion? ....from within the VM subsystem?
There are some points in the kernel at which you just cannot touch the parts of the VM subsystem that would be necessary to dynamically allocate memory. It's not a design flaw; it's just a constraint of the way locking and reentrancy have to be handled.
With a lot of work, you could probably create a dynamically allocating printk(), but you'd have to introduce a tremendous amount of additional locking just to support printk(), which would kill performance, and would mean that printk() couldn't be used in many places that it is now (certain interrupt handlers where the locking overhead would be too much).
Also, an obvious one
The static printk() buffer is a necessary design decision.
DNA just wants to be free...
As a longtime UNIX admin who's used many UNIX systems, I think this is a good thing. I don't mind text printing on startup, but Linux prints so much ABSOLUTE USELESS CRAP to screen.
90% of them are ego-boosting messages by the authors of each chunk of the kernel. These are in particular what Linus seems to have an issue with.
I don't think boot messages should be completely gotten rid of, but they should be put on a rigorous diet. Let's look at the way other Unices do it. FreeBSD, for example, prints stuff, but it's terse and professional looking. Same with Solaris.
On Linux, the messages scroll so damn fast, especially on a speedy modern system, that you can't even read them. That's bad, folks. I can't even tell if the kernel is printing any error messages, because the credits messages scroll it so quick.
Yes, I don't mind a kernel component telling me it's there and the hardware's functional, but don't be so verbose about it!
You ought to pass that book on to the MS Access developers. Does this sound familiar?
"You are about to modify 0 records. This action cannot be undone."
The Outlook people could use some help, too:
"This graphic does not do anything. For Help on an option, click tho question mark [?], and then click the option."
--
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Out the outset, let me say that I agree that kernel advertising/credits messages hide useful information and make the system unnecessarily confusing to less experienced users. I am glad to see Linus taking aim at them, as it really takes someone very respected in the development world to attack something that has so much ego attached to it.
That said, I would like to still have a verbose mode that includes these messages so that someone who knows what they are doing can verify that a given facility is being initialized at boot. The simplest way to achive this would be to change DEFAULT_MESSAGE_LOGLEVEL in linux/kernel/printk.c, from 7 (KERN_DEBUG) to 6 (KERN_INFO), thereby filtering out KERN_INFO messages. Maintainers who feel that some of these messages really should be printed by default could submit patches to change them to the previously ill-defined KERN_NOTICE (5) level and try to convince Linus to apply them.
It is also trivial for individual Linux distributions and sysadmins to modify this policy by booting with the "debug" argument (sets console_loglevel to 10) or to modify this in a boot script by writing to /proc/sys/kernel/printk as documented in linux/Documentation/sysctl/kernel.txt. A "loglevel=n" kernel boot argument would also be a helpful feature for the future and would be trivial to add.
This way, there would be several modes, selected by kernel parameters in the lilo.conf file or LILO prompt.
Meldroc, Waster of Electrons
"Unnecessary messages are pure evil."
- Everett N. McKay, page 367
Developing User Interfaces for Microsoft Windows
(c) Copyright 1999
What's your damage, Heather?
So, he's just talking about copyright notices and that sort of garbage. He's actually keeping the good stuff in. So, this makes sense. Must be a slow newsday, what with no Micro-Soft FUD to report.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
Relying on dmesg to configure a kernel (like the person you replied to) is kinda like relying on the author/editor blurb at the top of a Slashdot story to give an accurate impression of the news (like the person you replied to).
Jesus was all right but his disciples were thick and ordinary. -John Lennon
If you bother to read Linus's message, you'll note that this will not eliminate messages scrolling by on bootup. This will simply eliminate the display of suplimentary information that isn't crucial to the booting process.
For instance, you will no longer see:
Random Device Driver: Initialized
Random Device Driver version 1.23 (c)1999 John Doe
You will simply see:
Random Device Driver: Initialized
The other stuff is available elsewhere, and just adds to the clutter. Simple == beautiful.
Linus specifically said that the important kind of messages are the ones that are displayed when something isn't working properly,
/var/log/messages and I happen to notice that you're running the 2yr old ReiserFS code with the security hole, I'll tell you and you will be happy. But because there isn't a problem, ReiserFS doesn't ever say anything and you get cracked.
You see, the problem is that software often doesn't KNOW when something isn't working properly. The software cannot know unless the developer either:
1)predicts every possible failure case or,
2)checks the inputs at every function call (which will slow your 1000GHz Fitztanium to 8086 speeds)
Version numbers are also important. If you show me your
Bootup messages are a very important standard that has become an invaluable troubleshooting tool. Even know that something DOES work is good information when troubleshooting. Linus should leave it alone. If I don't wanna see "ReiserFS is brought to you by MP3.com", I'll either modify it (I do have the source), or I'll use IBM's JFS.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
For all the Windows flames that get thrown around here, I think MS hit the nail on the head with the Windows 9x series. (Well, boot screens that is...) The Windows 9x series had the best of both worlds: A pretty picture (animated even!) that was shown while the system was booting, but if you wanted to see DOS messages, just hit escape and you're greeted with the standard DOS bootup.
/CRASHDEBUG option. It's not particularly pretty, but serves kind of the same purpose. It's just not available with an escape key. You can't set the option (easily) if you can't boot the system, so what's the point?
I think Linux should do the same thing - leave the bootup messages, debug messages, and whatever else there, but cover it up with a penguin sitting in a speedboat. For 95% of the time that I don't care what happens as long as the thing boots, I'll see my happy Tux, but for the other 5% of the time, I can just hit escape to see all the messages I've grown to know and lov^H^H^Hhate.
Windows 2000 doesn't offer this functionality. Yes, yes, I know about Windows 2000's
"Of course that's just my opinion, I could be wrong." - Dennis Miller
LOAD "SIG",8,1
LOADING...
READY.
RUN
Traditionally, in UNIX environments, the lack of a message indicates success. If it worked, why bother me about it?
This is important because I've seen *lot's* of people panic when they get success messages.
Pretend you know nothing of IRQs, IO ports, and hex numbers. If you saw a screen full of them you wouldn't know if it was good or bad. An important part of useability is not confusing the user, because they get very worried when they see something confusing.
We need the messages printed at boot time to be classified. You can have success messages, failure messages, credits, etc. Then you could configure the system to display the kinds of messages you want to see.
I don't know much about the innards of the kernel, but I suspect something like this already exists. Could it be used for boot messages? Perhaps it could be extended?
--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
My analysis isn't that Linus is killing dmesg, but rather he is responding to advertisements and junk clogging up needed boot and debugging messages. I agree with this. Have you seen what an AOpen motherboard boot screen looks like? On some models there is a right frame with all sorts of advertisements for all sorts of products. That is insane.
Linus isn't killing boot information but rather not placing everything from URLs to copyright information in the same place where you find out if your networking interfaces are functioning properly.
Linus specifically said that the important kind of messages are the ones that are displayed when something isn't working properly, so no more whining that you think those messages are going to disappear, okay?
Moreso, some people seem to be under the delusion that the linked Slashdot article with the "pretty bootup" is related to what Linus said. No. Linux isn't saying anything at all about a graphical boot, and that graphical boot system is still hugely experimental anyway.
--
Win dain a lotica, en vai tu ri silota
I've always felt since day 1 of using Linux that about half of the kernel output was ego-stroking, and very little useful information. It made the whole thing feel less like a unified project and more like a haphazard collection of little bits and pieces.
I hope the opportunity will also be taken to give everything a more unified look, a la commercial UNIX and *BSD kernels; it will certainly make finding what you're looking for in the dmesg much easier rather than having to sift through rabble.
Naturally, this means that a dmesg output doesn't give you any idea of what a system is running, but we have other better ways of displaying that through for example the proc interface.
um the way i read this is that linus doesn't want our dmesg full of crap about the maintainer's email address and other gobbledy gook that just doesn't matter. all i want to see on boot up is
keyboard.......ok
mouse..........ok
modem..........hosed---->read such and such to fix problem.
monitor........doing better than the modem apparently
-
I didn't get that _at_all_ from what Linux said. Given that he first said that there weren't any extranious messages, I think that what he meant was that only those items of a completely non-useful nature would be removed.
What does that mean? I think it means that stuff like:
Jun 6 13:10:04 localhost kernel: hdc: ATAPI 1X CD-ROM drive, 32kB Cache
eth0: PCnet/PCI II 79C970A at 0x1000, 00 50 56 8e 6e 4d assigned IRQ 9.
will stay around. But stuff like:
pcnet32.c:v1.25kf 26.9.1999 tsbogend@alpha.franken.de
which (arguably) provides little information will go away.
I really don't think there's any intent to take away boot messages.
Sean.
That what's being said is that the modules shouldn't be spitting out this information as part of their code, as modprobe could handle that function. It could then be turned on and off as needed. Makes sense to me, why does every kernel module need to have code in it to print out information when the software loading the modules could do it, it would then only be written once, could be configurable. (verbose level = X, or modprobe -v, modprobe -vv, modprobe -vvv, etc.)
If it fails, print out a message "Module X failed to load. Noncritical error, continuing to load linux. Fix me if you dare."
I'm going to go back in my box and will think within the limits of my box: MS Sucks Linux Good I read too much Slashdot.
Everyone knows we never have reboot our Linux boxen anyway. ('cept to add new hardware of course.)
'Same speed C but faster'
contacting host slashdot.org..... connected
slashdot.org contacted.... waiting for reply
downloading slashdot.org 10.5k/s
document:done
welcome marcus brody
congratulations! you have moderator satatus...
please go forth and moderate
words speak a thousand pictures. so much so, we often take the information they contain for granted.
what does some flying windows or clouds tell you exactly??
well... if they freeze you know your computer has crashed.
Linus: "Let's make it policy that we _never_ print out annoying messages that have no useful purpose for debugging or running the system, ok?"
Dont worry - Linus isnt going all Mac on us! As ever he is making more sense than your average hacker. I know what OS I'm running - and which kernel version, and even what modules im using. but yes some of this information is occasionly useful, and these are the bits that should be left. Maybe then they might not scroll off the screen so fast that we never read them anyhow.
Flying Headless Goku - version 0.8 (the other 0.2 would be the head)
thinking of idea
considering approaches
initialization complete, beginning typing
I dont' se e the protlem with verbose messages, you can just ignroe tem if you're not interested in what they say.
spellcheck:
dont': don't dent donut
don't
se: sea see is se.cx
see
e: a
ignroe: ignore
ignore
tem: Tim term team them
them
finished processing!
I don't see the problem with verbose messages, you can just ignore them if you're not interested in what they say.
--
Small precision on OSX:
/. =)
it has a verbose option ("Apple key+ v" at system boot) wich looks like good ol' *nix boot.
And it supports color !
I bet it can make coffee too =)
--
Arnaud Willem
1st post of my life on