public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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