Messages in this thread | | | Date | Thu, 10 Dec 1998 19:50:28 -0500 (EST) | From | Robert Minichino <> | Subject | Re: Kernel messages, I18N, etc. (Was Re: [PATCH] modify console_loglevel from commandline) |
| |
> Date: Thu, 10 Dec 1998 15:57:13 -0800 > From: Bruce Korb <korb@datadesign.com> > > Have you read some of my missives about internationalization? > I'll send you my program tomorrow, too. (It is at home.)
Yes, I have read all of them AFAIK.
> > The first disadvantage cannot be avoided, but the task is easily > > parallelizable as illustrated above. The second can be alleviated by > > shipping the kernel with a bug-reporting script, or having syslog log > > both english and internationalized messages (idea!). Actually, the > > bilingual logging idea would solve the logfile reader problem too. Hmm... > > I still think a binary log is better. > You do not have to parse out the insertion values. > It is smaller. > It allows programs to monitor events without having to parse text. > (Who says the data are only delivered to syslogd, anyway?)
A separate binary output is no doubt better. Perhaps a three-tier structure instead of the current two-tier kernel/syslogd:
kernel --(binary messages)--> binlogd --(int/english messages)--> syslogd | | | (int messages) (binary messages) (int/english messages) | | | v v v screen logs logs
Instead of binary per se, I do believe that sticking to a (barely) human-readable text-based format would be a better move, at the very least to keep consistency with the rest of the OS. (/proc entries are text, so why shouldn't log entries be text?) Perhaps something like this:
(Service, Event: Parameters)
0x00000004, 0x18c8ab2e: "08:01" 0x00000004, 0x82a1f5d0: "ext2" " readonly"
Instead of "VFS: Unable to mount root filesystem on 08:01" and "VFS: Mounted root (ext2 filesystem) readonly." Not very human-readable, but if you knew what you were looking for, you could find it.
The kernel however NEEDS to have internationalization information available to it so that it may give boot messages. We could conceivably make it part of initialization so we can get rid of it once the kernel boots. We have a few options (not an exhaustive list):
1) Rip -all- the messages out of the kernel and replace with numeric ids. 2) Rip all the messages out of the kernel as we currently know it and put it in a table. Let the table be ripped out of the kernel and replaced with loadable modules (initmem?). 3) Leave the messages in the kernel. Have printk() look up a hash of the message in an internationalization table. If the table does not exist or if it is not found in the table, it just prints the message, otherwise it prints the internationalization.
Advantages of each:
1) Kernel shrinks considerably, and messages are guaranteed to be unambiguous. 2) Kernel gets slightly larger at boot, but shrinks afterwards. 3) Kernel stays roughly the same size with no internationalization, easy to add new messages, do not need to internationalize every message, adds almost no complexity.
Disadvantages:
1) Managability nightmare. What does "!! 0x109ab24d: 0x10002001" mean? Maintaining the codes is a maintenance nightmare, and inconvenient for debugging, requires every message to be catalogued. Remember, we're dealing with a moving target here. 2) Adds much complexity, esp. to compilation process, possible source of fatal bugs, not very elegant, requires every message to be catalogued. 3) Doubles size of current kernel messages in kernel for non-english versions, but only if all messages are or need to be internationalized.
My favourite is #3. A binary-log in addition to #3 would be excellent. One wouldn't have to internationalize the kernel in order to benefit from internationalized logs, and log parsing tools would be much simplified. This would also require no modification to syslogd. It is also the least intrusive, requiring no significant change in behaviour on the part of other kernel developers. Tagging kernel output with the binary codes allows maintainers to understand errors even in internationalized kernels.
I can't wait to see Linux panic in swedish chef. :) I think an "ultrageek" would be fun too:
Unrecoverable kernel error: Unable to detect, access, and/or recognize the structure of mass-storage device (MAJOR:MINOR) 08:01 in the process of assigning it to the root mount point; CPU immobilized.
-- Robert Minichino Chief Engineer Denarius Enterprise, Inc. http://www.denarius.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |