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/