Messages in this thread |  | | Date | Wed, 15 Jan 1997 14:39:21 -0500 (EST) | From | "Adam D. Bradley" <> | Subject | Re: 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:
#ifndef LINUX_LANGUAGE #define LINUX_LANGUAGE_ENGLISH #endif #ifdef LINUX_LANGUAGE_ENGLISH #define FD_DISK_CHANGE_DETECTED "Disk Change Detected" #define FD_DISK_SCREWED "Your Disk is Screwed" /* etc etc etc */ #elifdef LINUX_LANGUAGE_JIVE #define FD_DISK_CHANGE_DETECTED "Yo dis be diff'd" #define FD_DISK_SCREWED "Yo disk be like yo mama!" /* etc etc etc */ #endif
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:
init_module() { /* delete original language heap, create a new one, repeat everything from setup_language() */ }
Or a temporary-override-type:
char *NewLanguageHeap = NULL;
init_module() { /* kmalloc a new heap */ /* Set appropriate pointers */ }
delete_module() { setup_language(); /* since LanguageHeap already exists, s_l can simply (???) re-set the pointers w/o worrying about another kmalloc() */ kfree(NewLanguageHeap); }
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 linking.
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 ;-).
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 <><
|  |