Getting the message from the kernel [LWN.net]

Getting the message from the kernel

Posted Jun 22, 2007 7:48 UTC (Fri) by adi (subscriber, #7892)
In reply to: Getting the message from the kernel by error27
Parent article: Getting the message from the kernel

Well, if you are the specialist on a particular topic the message itself might be sufficient and sometimes indeed be self-explanatory to you, perhaps even knowing/understanding the source code, having read it so many times.

However, if you are "just" a sys admin managing a large variety of systems you appreciate any help the system - with the plethora of things that can go wrong - can give you identifying problems, understanding what they were caused by, validating their respective impact, and proposing possible remedies without having you to dig into Linux kernel sources first. Except rare cases the message itself can't give you all this information and we certainly don't want novels to be issued as messages curing this inherent deficiency.

I understand that such approach suggests a kernel programmer to accept that messages indeed define some form of event mechanism others are dependent on processing for problem determination and automation and you may go that far that they indeed become some form of committed interface, hence doing the printk more consciously and prudently ...

(Log in to post comments)

Getting the message from the kernel

Posted Jun 22, 2007 18:17 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Except rare cases the message itself can't give you all this information and we certainly don't want novels to be issued as messages curing this inherent deficiency.

The right length of a message is somewhere between the traditional length and a novel. And it's the same length as developers would write in the "documentation" comment or database or whatever under the message ID proposals. The message manual will not have a novel -- it will contain a few sentences. And they will be fairly inaccurate.

The article talks about the long history of message IDs, but fails to put it in its historical context. Those first message manuals went with systems where storage (including disk space) was so precious you couldn't afford to put a text description of an error in it. The actual error messages had less than 12 characters of text, so they also had a message ID, which was an address in cheap tertiary storage: the paper manual.

Technology has progressed to where it is now a waste of resources to have a person look up a message. It's more efficient to have the computer just tell you what's wrong. But we've stuck with the tradition of terse error messages. They're usually one sentence or less, and in the Unix world, 3-4 words is considered ideal. Only part of this can be explained by programmer laziness; the rest must be just custom.

Other benefits of message IDs have been given here: enabling translation and searching problem databases. But enabling error messages to remain coy and withhold the majority of the information from you isn't one.

Getting the message from the kernel

Posted Jun 22, 2007 21:24 UTC (Fri) by im14u2c (subscriber, #5246) [Link]

Hmmm... there's a tradeoff. Verbose error messages are very useful for the beginner, or for obscure error messages that happen very rarely. Terse error messages are more efficient, especially for errors that occur often.

Compare "permission denied" to "Your currently active user id, 'im14u2c', does not have write permission on the file '/tmp/xyzpdq'. This file is owned by 'im14u2c', but the user write permission bit on the file is not set. Please consult the 'chmod' man page."

The latter is very friendly to a new user. Just awesome. But, it would get real old real quick. And, depending on the context, the advice implied by the error message (in this case, chmod +w is implied) might be wrong advice. (For example, what if the file in question is an RCS controlled file that isn't checked out?) Perhaps a settable "user expert level" needs to be specified to indicate how chatty the system should be?

Getting the message from the kernel

Posted Jun 23, 2007 2:16 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

I don't think it gets old like you think it would. To know, you'd have to try it for a while. I use a lot of software that prints out 5 line error messages on a terminal (because I wrote the code) and it really doesn't bother me. And consider that a lot of programs respond to the most casual error of them all -- fat-fingering -- by not issuing an error message at all but just dumping the full command syntax on the terminal. This seems to be quite popular.

Incidentally, I've found it's rarely a good idea to give advice on how to fix it in the message; the best you can do is to describe the problem. Same is true for a message manual -- the complete set of advice would be a textbook.

And I've tried the expert/novice thing (as a user), and that doesn't work. You're never expert enough that you know all the errors. But maybe something that avoids issuing the same verbose message frequently.

But really, that's all beside the point because we're talking about kernel messages. The kernel isn't interactive -- these things go primarily in a log thousands of lines long.