Organizing kernel messages [LWN.net]

Organizing kernel messages

Posted Oct 1, 2010 18:58 UTC (Fri) by giraffedata (guest, #1954)
Parent article: Organizing kernel messages

Rather than a message manual to find out what a kernel message means, I'd prefer that the kernel just say what it means.

Message manual technology goes back to a time when disk space and memory were so expensive that the OS couldn't afford to display more than a code; paper and operator time were cheaper.

There is still an obvious bias on the part of many software developers toward making computers tight-lipped, giving just a hint as to what might be the problem when something fails. But there's really no reason the kernel can't be more user friendly.

Having informative messages also removes much of the need to find the line of code that issued the message, as that's usually an attempt to find out what the kernel was trying to say.

And with detailed error messages, I think searching the code or the web for the text would be as easy as searching for an arbitrary message identifier.

to post comments

Organizing kernel messages

Posted Oct 1, 2010 19:55 UTC (Fri) by jeremiah (subscriber, #1221) [Link]

This doesn't nessicarily address the automated tools. Although I do tend to agree with your saying. I don't know if the CRC32 will really be any better, but I'd love to have an automated response system for kernel messages based on som expted ID as opposed to some random text. The nice thing about this system, is that you can dig into the ID's and look for situations you didn't know could happen because you didn't look at a particular peice of source to see what kind of messages it could produce. Although i guess one could grep all of the printks() in the source right now, and get a full list, but that smells funny to me.

Organizing kernel messages

Posted Oct 3, 2010 17:55 UTC (Sun) by error27 (subscriber, #8346) [Link]

It's a tautology that good error messages are good. But one thing about help files is that you can update them after the fact. If some new hardware is released with a buggy BIOS then the help file can tell people how to install the work around patch. Here again, having the git version would is usefull.

Organizing kernel messages

Posted Oct 8, 2010 19:39 UTC (Fri) by roelofs (guest, #2599) [Link] (1 responses)

Message manual technology goes back to a time when disk space and memory were so expensive that the OS couldn't afford to display more than a code; paper and operator time were cheaper.

Memory is still expensive, it's just that now we measure the cost in performance (think "cache miss"). A paragraph of useful description for each of 75,000 printks? No thanks... (Not that most developers are willing or even necessarily capable of writing a paragraph of useful documentation.)

And, of course, it need not stop there: a wiki could provide not only the paragraph-length descriptions but also user experiences, e.g., "I also saw that in this other situation that seemed unrelated, but because of foo bug and baz fallthrough, it triggered."

And with detailed error messages, I think searching the code or the web for the text would be as easy as searching for an arbitrary message identifier.

Um...have you ever tried? Finding copies of the same message is trivial--millions of logs are exposed on the Net. Finding the one-in-10000 web page where somebody quotes the message and actually describes the fix (or at least the underlying problem) is damn near impossible. (Kernel errors might be more amenable to it than gcc/binutils errors, but I wouldn't bet on it. Even the number of forums containing orphaned what-does-this-mean / how-do-I-fix-this? postings--or postings with useless / outdated / incorrect responses--is ridiculously high.)

Greg

Organizing kernel messages

Posted Oct 9, 2010 16:28 UTC (Sat) by giraffedata (guest, #1954) [Link]

Memory is still expensive, it's just that now we measure the cost in performance (think "cache miss"). A paragraph of useful description for each of 75,000 printks? No thanks

I don't see how long error messages would cause appreciable cache misses or other slowdowns. I note that printks rarely execute and string literals are stored in a separate page from the rest of the stuff the program is likely to be accessing.

I hope there aren't people scrimping on messages (in any program) because they think they cost too much performance.

And with detailed error messages, I think searching the code or the web for the text would be as easy as searching for an arbitrary message identifier.
Um...have you ever tried? Finding copies of the same message is trivial--millions of logs are exposed on the Net. Finding the one-in-10000 web page where somebody quotes the message and actually describes the fix

I agree that searching the web for message text is a poor way to diagnose a problem for the reasons you give (so I'd prefer that the program just tell me what the problem is), but how is searching the web for a message number any better? I've done both.

Note that I switched context in my original post, addressing two separate advantages of message numbers discussed in the article: 1) message manual ala VMS, and 2) Google.