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

    #ifndef LINUX_LANGUAGE
    #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.022 / U:9.072 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site