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