Recent Features
| |||||||||||||
Getting the message from the kernelGetting the message from the kernelPosted Jun 21, 2007 4:40 UTC (Thu) by error27 (subscriber, #8346)Parent article: Getting the message from the kernel
Is there any need to put docbook style comments on a printk? Shouldn't the printk itself be self explanitory like "b44: eth0: Link is down." Probably if users don't understand the printk they aren't going to understand the comment either.
(Log in to post comments)
Getting the message from the kernel Posted Jun 21, 2007 6:44 UTC (Thu) by thedevil (subscriber, #32913) [Link] Right, exactly my sentiment. The whole _idea_ of adding a "unique ID" seems rubbish to me: isn't the message string _itself_ already unique? If it isn't, it's just a handful of cases and it can easily be checked mechanically at each release. And how is some cryptic thing like RLGNERR100 better than "Railgun error 100" ??
Getting the message from the kernel Posted Jun 21, 2007 7:47 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] no, the message itself is not always unique.
remember that messages are formed through printf, where you give a message format with variables and then have the variables fill in the blanks
it's not at all uncommon to see something like "error %s happened when doing %s"
depending on what the variables are filled in with you could have this happen anywhere in the kernel.
on a lot of my programs I add a number to the front of the message, even if it isn't unique it at least limits the number of places I need to look. the line and file macros mentioned above sound like exactly the right thing to use.
the main purpose of these tags is to look in the right place in the kernel, not to try and translate all possible kernel errors into multiple languages.
Getting the message from the kernel Posted Jun 21, 2007 10:12 UTC (Thu) by ayeomans (subscriber, #1848) [Link] Why not just do a hash function of the message string? Into (say) a 32-bit number. Any duplicate hashes could be treated as a bug and modified.
Should be a fully automatic job to scan the entire source for the printk strings to get the hash values, source file name (and line number if you wish). The catalogue could be used for translations, documentation, etc. And would not in itself create any extra work for kernel maintainers, apart from the occasional change to fix duplicate hashes.
Getting the message from the kernel Posted Jun 21, 2007 10:18 UTC (Thu) by ayeomans (subscriber, #1848) [Link] And having subsequently read the thread, that's just what is being proposed by many there.
Getting the message from the kernel Posted Jun 21, 2007 17:07 UTC (Thu) by cpeterso (guest, #305) [Link] Even if all printks were unique and self-explanatory, they are written in English. Many users would prefer localized messages in their native language. An id # allows that.
Getting the message from the kernel Posted Jun 22, 2007 7:48 UTC (Fri) by adi (subscriber, #7892) [Link] 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 ...
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 jzbiciak (✭ supporter ✭, #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.
|
|||||||||||||