kernel support for non-English user messages
Quoted 6 lines · Alan Cox
You are right about needing to log parameters, but given a log line of the form
%s: went up in flames\n\0eth0\0\0
that can be handled by the log viewer
I still see some problems...
For one, there are 131 instances of:
printk("%s\n", blurb);in various forms in 2.5.66. Besides possible ritual immolation of those responsible for such things, something would have to be done about them.
Another problem is the one of getting that text onto the console
in readable form. The only thing I can think of is have a two-stage process where printk puts the data into the log buffer as zero-terminated strings and then the console write routines format it for display. They'd probably need their own buffers to do that.
Quoted 1 line
%s: went up in flames\n\0eth0\0\0
Is that "\n" an actual ASCII newline or the printk escape sequence?
--
"Let's fight until six, and then have dinner," said Tweedledum. --Lewis Carroll, _Through the Looking Glass_
Quoted 8 lines · Chuck Ebbert
Quoted 5 lines · Alan Cox
You are right about needing to log parameters, but given a log line of the form
%s: went up in flames\n\0eth0\0\0
Quoted 8 lines
Quoted 1 line
that can be handled by the log viewer
I still see some problems...
For one, there are 131 instances of:
printk("%s\n", blurb);
[SNIPPED....]
There are 48,038 printk statements in linux-2.4.20. The text portion of those statements comprises 307,136 bytes, excluding modules!
This print-your-way code has more ASCII than MBASIC. It is patently absurd and some people are trying to legitimize this text bloat with a translation utility. Fork the kernel and make it text-based if you want, but we need to remove most of this text on the standard kernel, not make it somehow seem right. It is wrong, just plain wrong, and it's getting worse as time goes on.
Every one of those printk-drivers should have an ioctl() so that some user-mode program can check on its health, how many SCSI disks got found, what the Ethernet parameters are, etc. This is not something that should be printed on the screen every time the machine boots for the one-time-out-of-1000 that a disk didn't come on-line or the network didn't come up. Most all of the error reporting within the kernel is being done without regard to what used to be called "good standards of engineering practice".
BSD also has this problem but you would expect that from students because they become amazed as their driver starts to work and they proudly print every intermediate step in the initialization. Professionals should know better and do better work.
Properly running software is indistinguishable from magic and it is completely invisible to the user.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.
Quoted 1 line · Chuck Ebbert
Alan Cox wrote:
...
Quoted 7 lines
I still see some problems...
For one, there are 131 instances of:printk("%s\n", blurb);in various forms in 2.5.66. Besides possible ritual immolation of those responsible for such things, something would have to be done about them.
Think again. In case the "blurp" COULD have "%" in them...
Quoted 5 lines
Another problem is the one of getting that text onto the console
in readable form. The only thing I can think of is have a two-stage process where printk puts the data into the log buffer as zero-terminated strings and then the console write routines format it for display. They'd probably need their own buffers to do that.
Many of kernel's terse messages do need small encyclopedic articles to explain them. Present gobble-de-gook can not be made clear by merely supplying l10n translations of them to other gobble-de-gook.
Having ANCIENT STYLE numeric message code references will help users
to find definitive explanations of them. "My machine said:
'1-00234-0627 eth0 link down' and then it said: '1-00234-0626 eth0 link up'" (Where initial digit is severity qualifier, then subsystem id, and finally codepoint within subsystem. All within 32-bit integer.) (And probably base64-ish presentation in dmesg buffer, not base10..)
Some tool can produce HTML hyperlinked presentation of the messages with colour coding telling message classifications as text line backgrounds:
green: info/chatty, can ignore
blue: something notable happened (like linkstate jumps)
yellow: something possibly serious
red: something definitely serious
at the same time the tool can produce hyperlinks with user's language preferences (picked from environment/desktop parameters), and point all that to some site with e.g. a twiki to accumulate documentation. Vendors could also pull database snapshots into those tools.
That message-code style was introduced, when machines had very little memory, but style being in use from the dawn of computing is not a good reason to shun it. It really has benefits.
Quoted 3 lines
Quoted 1 line
%s: went up in flames\n\0eth0\0\0
Is that "\n" an actual ASCII newline or the printk escape sequence?
The backslash is not "printk escape". It is C-string compilation notation.
/Matti Aarnio