Messages in this thread |  | | Date | Wed, 15 Jan 1997 22:33:30 -0500 (EST) | From | "Adam D. Bradley" <> | Subject | Re: Jive -> Kernel (International Linux) |
| |
> > > 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 example snipped]
> > And use the defined constants in printk()'s instead of literal text. > > Hrm. Actually, this is a _very_ good idea anyways for reducing memory > space, but it has implications that make it possibly a bad idea.
It's pretty much a zero-overhead solution, maybe even a small win if GCC is smart about literal string constants and we're careful about replacing "strinkingly similar" printk's with single constants. Two problems: (1)purely static, ie, this stuff can only be changed with a recompile, and (related issue): every source file that uses printk() would need to include printk_strings.h, so any change to a single string constant for a single source file forces just about everything in a directory to be re-compiled. We could move the constants to the individual source files, but that becomes unweildy for any one person seeking to do a "total translation"; easier to make the changes in a central registry.
> Anyways, here's what WWIV BBS software did to handle these problems > (no RAM, multiple languages, etc): > We have a file called BBS.STR with 512byte (or 256byte?) entries. > Then a function like char *get_string(int x); So we'd do like > pl(get_string(1)); to print the first string out to the serial port. > Of course, this is just how WWIV did it. we'd want variable length > records. And we'd wanna have a smart parsing program to rip out strings > automagically. But the concept of putting these into a cached (to avoid > disk thrashing when you have a repeating message) file could probably solve > these problems. In WWIV, a simple cache of the most recent 100 messages or > whatever was used, though we could just as easily leave the cache up to the > file system code.
I think it's a patently Bad Idea (TM) to make kernel messages dependent on access to a filesystem. The bulk of the kernel's communication with the console is either boot or error related (and a good share of those errors can be file-system related, in my experience), so we get only a minimal win by putting a small subset of the string table on the filesystem, at high cost to complexity (distinguishing "classes" of strings, different code types to get internal and file-stored strings, etc...)
As for the cache, here's an idea: Have a dummy user-space process (say, "klanguaged") that we can use to hold the string heap. Since it's userland, it's swappable (ie, no unswappable-kernel-allocation bloat). We still need to keep system-critical messages (everything relating to OOPS's and panics, for example) in kernel-space, but this would perhaps be an acceptable compromise for the rest. Problem #2: allocating the process at the very beginning of the boot process.
> The biggest problem with this, however, is a big one...we'd need to > have the file system accessible at all times in order to get_string > successfully. Sure, we could preserve certain special files (like > filesystem and boot stuff) to tell the parser not to do any replacements, > but we still get a lot of complexity from this. And maintaining a database > such as the string database would be a really big pain, though not nearly as > bad as I managed to make my WWIV database.
I've been thinking about the dynamic suggestion I proposed earlier. If we could implement Dave's "disposable init segment" feature in the i386 compile, it becomes a very promising option (see below).
Consider the "String-Heap" solution I proposed before.
Given: The kernel already has to store all strings as literal constants somewhere in its data space. So why force these to be static? Why not replace them with normal pointer variables that can be changed by an "Internationalization module" or "language module" as needed?
The trick is in initializing the heap space...for the best portability/interchangability/etc, I suggest tdefault setup_language() routine, along with all the associated string constants, be in a disposable-init section, so once the heap is built, the string constants in the init code can "go away" and prevent run-time kernel bloat. Same with modules - a Language Module could, upon loading, use its internal strings to re-build the String-Heap, then immediately force its own unloading, so its internal string table doesn't occupy kernel memory unnecessarily.
I'm going to throw together a few demo routines for this String-Heap approach, for everyone's consideration. I would still like to know, however, if any _cares_ if something like this ever makes it into the kernel ;-) ...
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 <><
|  |