lkml.org 
[lkml]   [1997]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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 <><


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