[lkml]   [1997]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Jive -> Kernel (International Linux)

> > My system isn't "mission critical", so I want it Jived to say, "Sheeeit, slap
> > mah fro!" instead of "Kernel panic!". More than just that, all the printk's.
> Rather than some pigin English what about French, German, Finnish, etc etc ?
> Ok, so Jive could be added too. :-)
> This would definitly have to be a compile time feature arranged so that it
> doesn't cost any extra code/data space in the kernel, it may make Linux
> the first truly international Unix kernel. :-)

This isn't a bad idea, really. We could do it as a compile thing, or
maybe even at run-time with modules...(hmm)...

For compiled-in language support:

In each directory, create a file "printk_strings.h" like this:

#define FD_DISK_CHANGE_DETECTED "Disk Change Detected"
#define FD_DISK_SCREWED "Your Disk is Screwed"
/* etc etc etc */
#define FD_DISK_CHANGE_DETECTED "Yo dis be diff'd"
#define FD_DISK_SCREWED "Yo disk be like yo mama!"
/* etc etc etc */
And use the defined constants in printk()'s instead of literal text.

To get more clever, we could do it at run-time. Have a universal "text
constants heap" somewhere in the kernel/ directory, say a new file
called "language.c":

char *LanguageHeap = NULL; /* this is important---see below */
(export as global symbols)
char *string_fd_disk_changed;
char *string_fd_disk_screwed;
/* etc etc etc */

And have a routine, called _very_ early in main():

void setup_language()
if (!LanguageHeap) {
/* kmalloc() a heap to use for "string space" */
/* Fill it with the necessary strings and set
the string_* pointers appropriately */
And use the appropriate string-pointer names instead of text literals
wherever appropriate. Now, language overrides can be done with a
loadable module. We can do a total-override-type:

/* delete original language heap, create a new one,
repeat everything from setup_language() */
Or a temporary-override-type:

char *NewLanguageHeap = NULL;

/* kmalloc a new heap */
/* Set appropriate pointers */
setup_language(); /* since LanguageHeap already exists, s_l
can simply (???) re-set the pointers
w/o worrying about another kmalloc() */
This could even be done on a per-driver basis, so there could be language
modules for each device driver or section of the kernel code.

Even better: these code segments could be written to be compilable into
the kernel, so setup_language() could be (according to a compile-time
environment variable) setup to call setup_language_french(), which is
an inline call to frenchlanguage.c's initmodule() (or visa-versa). To
get _really_ crazy, you could compile several languages into a kernel,
and have a boot option allowing you to select which setup_language_* to
call... Imagine, "LILO: Linux vga=778 language=Italian"

There will necessarily be some size overhead to retain the string symbol
table; "internationalization" could be a compile-time option, and if
switched off, we could (???) strip these symbols from the kernel after

Of coure, for this to work, driver-writers will have to switch over to
using pre-defining their text strings. This usually isn't a problem once
a driver is past alpha-testing, since the messages should be pretty well
pre-defined, and there's nothing to stop you from using literal strings
until then. Of course, OOPS's, panics, and the like should retain
"hard-coded" text constants.

I can work on coding this if anyone thinks it's a valid and worthwhile
idea...I speak some shoddy Spanish, Latin, and classical Greek, so I'll
have to leave internationalization modules to those more proficient than
myself ;-).

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 <><

 \ /
  Last update: 2005-03-22 13:38    [W:0.146 / U:0.188 seconds]
©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site