>
> > We could save text area space by moving all the printk and procfs
> > strings out of the kernel entirely, replacing them with a external
> > hash lookup. This would not only save text area space, but make it
> > easier to produce modules that output kernel error messages in
> > other languages than english.
That's bad. The kernel should be able to "talk" to the user without any,
maybe unaccessable, extern program.
>
> Ack! We hashed this out a few months ago!
Yes, I know... :/
>
> Summary:
> (1) Kernel messages don't occur often enough to be worth setting up
> translation tables, etc.
But for many people without too much experience these messages are very
important. You can say Linux is only for experts, but I think this is not
very nice.
>
> (2) Kernel messages in 100 languages makes it that much harder to deal
> with bug reports (since they need to be un-translated for the developer to
> know what's going on)
That's true. I think, Kernel messages needed only be in one language, but
with an standardized output. I told this a few weeks ago.
>
> (3) Some kernel messages (eg, Oops's and panics) are too critical to be
> kept in swappable memory (since it's a possible error spot).
That's really true...
> Additionally, one of the nice things about Linux is that so much of its
> interface is intelligible human-readable text, as opposed to other (herein
> unnamed) OS's that use things like a binary registry; to rely on a
> user-space daemon or translator to translate these things is a bad idea
> because:
> (a) versioning inconsistencies will show up: a translator for
> 2.1.X may barf on messages for a 2.0.X kernel, and many of us have
> multiple kernels on our systems
> (b) If the system becomes unstable, the binary messages may not be
> logged, and the translater may not be available to do real-time
> translations (what if ld.so becomes inaccessible?)
> (b2) similarly for a userspace daemon - it may be swapped out and
> become inaccessible/useless.
Why do you want to use a daemon? A normal program which parses the output
of the normal kernel messages and which does some translation is enough,
to help many peoples. If a kernel crashes, this application could run
after the next boot...
>
> (4) Maintaining an overridable multilingual message database will either
> result in massive code bloat (for non-run-time-updatable solutions) or
> kernel bloat (for run-time-updatable solutions), it it would be a royal
> pain in the @ss to make it an option which to compile.
Well, a database for error-message would be nice, but _not_ in the kernel
source. An extern database does the work also.
>
> In summary:
> "Internationalized user programs = Good Thing.
> Internationalized kernel = Not-Worth-The-Trouble Thing."
>
> It's a neat idea, but there isn't enough practical benefit to justify the
> increased complexity.
Hmmm, we just need to standardize the kernel output. I've searched in
kernel source for printk's and found over 10 000! So we need the help of
all developers to make a standardized, nice, parsable kernel output.
Translation and help to the outputs could made by an extern program.
The same thing should work with the outputs of daemons...
Sorry about my English and the long and maybe boring mail....
Dirk
>
> Adam
> --
> He feeds on ashes; a deluded mind has led him Adam Bradley, UNCA Senior
> astray, and he cannot deliver himself or say, Computer Science
> "Is there not a lie in my right hand?" Isaiah 44:20
> bradley@cs.unca.edu http://www.cs.unca.edu/~bradley <><
>
>
>