[lkml]   [2002]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [STATUS 2.5] July 10, 2002

Kurt Garloff wrote:

> If you want translated kernel messages, use message IDs, that can be parsed
> and translated in userspace,


What's been discussed with Rusty Russell (and I believe he has
discussed this with Alan) is not modifying the printks, but providing
logging macros that keep the format string separate from the vararg list
(but written to a log file as a single event record).

Then, a user-space utility would read the event record from the log
and do one of the following:
1) printf-style formatting with the original format string, just like
2a) Use a unique reference code (a hash, generated in the kernel, of
original format string with sourcefile name and function name, for
example) to look-up the non-english format string (similar to the
catgets approach).
2b) Use the format string to look-up its non-english equivalent in
a message catalog (similar to the gettext approach).

Rusty's proposal has many other benefits, which I will leave for him
to describe at the appropriate time, but translation in user-space of
kernel messages into multiple languages is one of them.

In fact, with event logging (not currently part of the base) you can
"fork" printk() messages both to the current ring buffer (formatted),
to a separate buffer where the format string and varargs list could
be kept separate, as described above.

Existing parsing scripts, sys admins, etc. expect /var/log/messages,
to have pure, unmodified printk messages, so you would not want to touch
the original printk messages. However, storing the unformatted event
separately in its own log file would allow the processing options
above. Also, if the variable event data is stored separately from the
format string in the event record, parsing of the data by a user-space
utility is cleaner and more efficient.

> if somebody really needs it.

Agreed, again. If you don't want/need translation, there must be a way
completely disable it and the extra overhead that makes it possible.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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