From: Larry Kessler <kessler@us.ibm.com>
To: Kurt Garloff <garloff@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
"Perches, Joe" <joe.perches@spirentcom.com>,
thunder@ngforever.de, bunk@fs.tum.de, boissiere@adiglobal.com,
linux-kernel@vger.kernel.org,
"'Martin.Bligh@us.ibm.com'" <Martin.Bligh@us.ibm.com>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [STATUS 2.5] July 10, 2002
Date: Wed, 10 Jul 2002 12:19:14 -0700 [thread overview]
Message-ID: <3D2C88B2.FF9ECD5C@us.ibm.com> (raw)
In-Reply-To: 20020710184922.GN12910@gum01m.etpnet.phys.tue.nl
Kurt Garloff wrote:
> If you want translated kernel messages, use message IDs, that can be parsed
> and translated in userspace,
Agreed.
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
printk
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).
or
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),
and
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,
etc.
to have pure, unmodified printk messages, so you would not want to touch
the original printk messages. However, storing the unformatted event
data
separately in its own log file would allow the processing options
described
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
to
completely disable it and the extra overhead that makes it possible.
next prev parent reply other threads:[~2002-07-10 19:19 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-10 17:46 [STATUS 2.5] July 10, 2002 Perches, Joe
2002-07-10 18:05 ` Thunder from the hill
2002-07-10 18:38 ` Alan Cox
2002-07-10 18:49 ` Kurt Garloff
2002-07-10 19:19 ` Larry Kessler [this message]
2002-07-10 21:15 ` Alan Cox
2002-07-11 18:07 ` Anton Blanchard
2002-07-10 21:27 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2002-07-11 20:34 Richard J Moore
2002-07-13 9:28 ` Ingo Oeser
2002-07-11 19:21 Richard J Moore
2002-07-10 18:08 Russ Weight
2002-07-10 5:11 Guillaume Boissiere
2002-07-10 15:49 ` Rik van Riel
2002-07-10 16:19 ` Adrian Bunk
2002-07-10 16:31 ` Thunder from the hill
2002-07-10 16:51 ` Roman Zippel
2002-07-10 17:00 ` Thunder from the hill
2002-07-10 16:54 ` Karim Yaghmour
2002-07-10 17:25 ` John Levon
2002-07-10 19:19 ` Karim Yaghmour
2002-07-10 17:17 ` Alan Cox
2002-07-10 20:21 ` Daniel Phillips
2002-07-10 17:12 ` Patrick Mochel
2002-07-10 17:42 ` Arnaldo Carvalho de Melo
2002-07-10 17:54 ` Robert Love
2002-07-10 19:18 ` Ville Herva
2002-07-10 20:03 ` Robert Love
2002-07-10 20:20 ` Cort Dougan
2002-07-10 20:25 ` Robert Love
2002-07-10 20:41 ` Ville Herva
2002-07-10 21:07 ` Alan Cox
2002-07-10 20:46 ` Robert Love
2002-07-11 9:46 ` Rogier Wolff
2002-07-10 20:26 ` Justin M. Forbes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D2C88B2.FF9ECD5C@us.ibm.com \
--to=kessler@us.ibm.com \
--cc=Martin.Bligh@us.ibm.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=boissiere@adiglobal.com \
--cc=bunk@fs.tum.de \
--cc=garloff@suse.de \
--cc=joe.perches@spirentcom.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=thunder@ngforever.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox