lkml.org 
[lkml]   [1997]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Kernel-Messages translation
Date
From

Stefan Hornburg writes:
>
> Why not add the translated messages to the original ones ?
> So the expert sees what he wants, and the user is also satisfied.
> If the translation is optional the configuration, kernel and other
> bloat is restricted to the ones who want the translation.

Because the kernel currently has 10765 printk() statements, for over
600k. Even if we translated all (!) of them, to just 1 additional
language, the kernel source tree would go up by over 1 meg!
(Why 1 meg? Well, lets do the math...)
#ifndef CONFIG_PRINTK_FRENCH
printk("The filesystem is corrupted\n");
#else
printk("Les filesystem est corrupte\n");
#endif

just the compiler directives are ~40 bytes (it could be done better)
So just the addtional #ifdefs result in 400k of code bloat.
If we assume that the translation takes up about as much space as the
original (like my horrible french example did. ;-) that means about
another 600k of french in the kernel. (Plus all the extra directives
when compiling... an additional 10k #ifdefs for cpp?)

Now, can we take all this bloat to a runtime translation utility? the
_ONLY_ thing that should end up in the kernel is a tag that says what
subsystem generated the printk... perhaps with a number for a userland
interpreter. The only reason THAT sould be in the kernel is because
find /usr/src/linux -name *.[ch] | xargs -n 5 grep "some message I saw" is such a pain.
;-)

Now that I have showed why this is a bad idea code-wise, and that it DOES
lead to massive amounts of bloat, can we drop this idea for the next six
months? Read the archives for more reasons why it belongs in
klogd-translate.

--Dan


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.057 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site