linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* kernel support for non-english user messages
@ 2003-04-09  5:02 Frank Davis
  2003-04-09  5:29 ` Oliver Neukum
                   ` (4 more replies)
  0 siblings, 5 replies; 137+ messages in thread
From: Frank Davis @ 2003-04-09  5:02 UTC (permalink / raw)
  To: linux-kernel

All,

I wish to suggest a possible 2.6 or 2.7 feature (too late for 2.4.x and 
2.5.x, I believe) that I believe would be helpful. Currently, printk 
messages are all in english, and I was wondering if printk could be 
modified to print out user messages that are in the default language of 
the machine. For example,

printk(KERN_WARN "This driver is messed up!\n", 'en'); //Prints the 
english text .

printk(KERN_WARN "This driver is messed up!\n", 'wel'); //Prints the 
welsh translation of the english text.

printk(KERN_WARN "This driver is messed up!\n", getdefaultlanguage());

I'm looking for a possible uniform design to make this happen, short of 
adding a complete machine translation module to the kernel. :) Userland 
internationalization support is already provided(I haven't personally 
used other languages besides English, but I've seen the options), but a 
kernel module or printk addition that handles localized kernel messages 
seems reasonable.

Thoughts, comments?

Regards,
Frank


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09  5:02 kernel support for non-english user messages Frank Davis
@ 2003-04-09  5:29 ` Oliver Neukum
  2003-04-09  5:50   ` Frank Davis
  2003-04-09 11:04   ` Alan Cox
  2003-04-09  5:53 ` Andreas Dilger
                   ` (3 subsequent siblings)
  4 siblings, 2 replies; 137+ messages in thread
From: Oliver Neukum @ 2003-04-09  5:29 UTC (permalink / raw)
  To: fdavis, linux-kernel


> I'm looking for a possible uniform design to make this happen, short of
> adding a complete machine translation module to the kernel. :) Userland
> internationalization support is already provided(I haven't personally
> used other languages besides English, but I've seen the options), but a
> kernel module or printk addition that handles localized kernel messages
> seems reasonable.
>
> Thoughts, comments?

These messages are for administrators and developers. Everybody needs
to be able to read them. They have to be in English.

	Regards
		Oliver


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09  5:29 ` Oliver Neukum
@ 2003-04-09  5:50   ` Frank Davis
  2003-04-09  9:37     ` Bernd Petrovitsch
  2003-04-09 11:04   ` Alan Cox
  1 sibling, 1 reply; 137+ messages in thread
From: Frank Davis @ 2003-04-09  5:50 UTC (permalink / raw)
  To: oliver; +Cc: linux-kernel

Oliver,

I'm not saying that the messages aren't in English; I'm saying that the 
messages don't *only* have to be in English on the output. The message 
in the kernel could remain as is, but the output kernel message would be 
tailored in the default language of the user's machine, so for example a 
Spanish administrator or developer wouldn't need to know English to read 
the kernel output. I don't think we can assume that all 
administrators/users or developers have English as their primary language.

Regards,
Frank

Oliver Neukum wrote:
> 
> These messages are for administrators and developers. Everybody needs
> to be able to read them. They have to be in English.
> 
> 	Regards
> 		Oliver
> 
> 



^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09  5:02 kernel support for non-english user messages Frank Davis
  2003-04-09  5:29 ` Oliver Neukum
@ 2003-04-09  5:53 ` Andreas Dilger
  2003-04-09  8:08 ` Matti Aarnio
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 137+ messages in thread
From: Andreas Dilger @ 2003-04-09  5:53 UTC (permalink / raw)
  To: Frank Davis; +Cc: linux-kernel

On Apr 09, 2003  01:02 -0400, Frank Davis wrote:
> I wish to suggest a possible 2.6 or 2.7 feature (too late for 2.4.x and 
> 2.5.x, I believe) that I believe would be helpful. Currently, printk 
> messages are all in english, and I was wondering if printk could be 
> modified to print out user messages that are in the default language of 
> the machine. For example,
> 
> printk(KERN_WARN "This driver is messed up!\n", 'en'); //Prints the 
> english text .
> 
> printk(KERN_WARN "This driver is messed up!\n", 'wel'); //Prints the 
> welsh translation of the english text.
> 
> printk(KERN_WARN "This driver is messed up!\n", getdefaultlanguage());
> 
> I'm looking for a possible uniform design to make this happen, short of 
> adding a complete machine translation module to the kernel. :) Userland 
> internationalization support is already provided(I haven't personally 
> used other languages besides English, but I've seen the options), but a 
> kernel module or printk addition that handles localized kernel messages 
> seems reasonable.
> 
> Thoughts, comments?

I don't think you will get support from anyone for non-english messages
in the kernel.  Some people think there is already too much text segment
in the kernel (c.f. tests that show kernel size shrinks by 200kB or whatever
when printk is defined to a no-op).

There was a proposal to make printks be more generic/consistent by someone
at IBM, but I don't know what happened to it.

My suggestion would be to add the required i18n support to klogd, so that
kernel messages are translated as they are removed from dmesg into syslog.
Then, like any i18n support, you build a message catalog from the printk
strings in the kernel and have klogd do the lookups/translation in user
space.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09  5:02 kernel support for non-english user messages Frank Davis
  2003-04-09  5:29 ` Oliver Neukum
  2003-04-09  5:53 ` Andreas Dilger
@ 2003-04-09  8:08 ` Matti Aarnio
  2003-04-09  9:33   ` Oliver Neukum
  2003-04-09 22:07   ` Werner Almesberger
  2003-04-09 13:11 ` Giuliano Pochini
  2003-04-10  3:08 ` Linus Torvalds
  4 siblings, 2 replies; 137+ messages in thread
From: Matti Aarnio @ 2003-04-09  8:08 UTC (permalink / raw)
  To: Frank Davis; +Cc: linux-kernel

On Wed, Apr 09, 2003 at 01:02:16AM -0400, Frank Davis wrote:
> All,
> 
> I wish to suggest a possible 2.6 or 2.7 feature (too late for 2.4.x and 
> 2.5.x, I believe) that I believe would be helpful. Currently, printk 
> messages are all in english, and I was wondering if printk could be 
> modified to print out user messages that are in the default language of 
> the machine. For example,

To propagate the idea further, why not have proper message catalogs,
and that way translations.  Instead of:

> printk(KERN_WARN "This driver is messed up!\n");

There would be:
  printk(KERN_WARN "1234-6789 this driver is messed up!\n")

In the old days of big iron beasts, there used to be multivolume
binders full of system messages, and their explanations.
Searching went thru those "1234-5678" strings.

There were sets of those manuals in a number of customer languages.

...
> I'm looking for a possible uniform design to make this happen, short of 
> adding a complete machine translation module to the kernel. :) Userland 
> internationalization support is already provided(I haven't personally 
> used other languages besides English, but I've seen the options), but a 
> kernel module or printk addition that handles localized kernel messages 
> seems reasonable.

Compiled in strings take up kernel space, which has better uses.
Even those code-labels take up space. If not much in kernel (in
form of e.g. 32 bit integers ?) then at least in the  dmesg  buffer.

> Thoughts, comments?
> 
> Regards,
> Frank

/Matti Aarnio

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09  8:08 ` Matti Aarnio
@ 2003-04-09  9:33   ` Oliver Neukum
  2003-04-09 10:24     ` Matti Aarnio
  2003-04-09 22:07   ` Werner Almesberger
  1 sibling, 1 reply; 137+ messages in thread
From: Oliver Neukum @ 2003-04-09  9:33 UTC (permalink / raw)
  To: Matti Aarnio, Frank Davis; +Cc: linux-kernel

Am Mittwoch, 9. April 2003 10:08 schrieb Matti Aarnio:
> On Wed, Apr 09, 2003 at 01:02:16AM -0400, Frank Davis wrote:
> > All,
> >
> > I wish to suggest a possible 2.6 or 2.7 feature (too late for 2.4.x and
> > 2.5.x, I believe) that I believe would be helpful. Currently, printk
> > messages are all in english, and I was wondering if printk could be
> > modified to print out user messages that are in the default language of
> > the machine. For example,
>
> To propagate the idea further, why not have proper message catalogs,
>
> and that way translations.  Instead of:
> > printk(KERN_WARN "This driver is messed up!\n");
>
> There would be:
>   printk(KERN_WARN "1234-6789 this driver is messed up!\n")
>
> In the old days of big iron beasts, there used to be multivolume
> binders full of system messages, and their explanations.
> Searching went thru those "1234-5678" strings.
>
> There were sets of those manuals in a number of customer languages.

If we do this, why not go the whole way?
Could we compute a hash value for every message that's not KERN_CRIT,
use it to create a table of messages and hashes and replace the messages
in the kernel image with the hash values leaving expansion to klogd?

	Regards
		Oliver


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09  5:50   ` Frank Davis
@ 2003-04-09  9:37     ` Bernd Petrovitsch
  0 siblings, 0 replies; 137+ messages in thread
From: Bernd Petrovitsch @ 2003-04-09  9:37 UTC (permalink / raw)
  To: fdavis; +Cc: oliver, linux-kernel

Frank Davis <fdavis@si.rr.com> wrote:
>I'm not saying that the messages aren't in English; I'm saying that the 

You just say it below: If the message on the console is in Spanish, 
it is no longer in English.

>messages don't *only* have to be in English on the output. The message 
>in the kernel could remain as is, but the output kernel message would be 
>tailored in the default language of the user's machine, so for example a 
>Spanish administrator or developer wouldn't need to know English to read 
>the kernel output. I don't think we can assume that all 
>administrators/users or developers have English as their primary language.

But as their secondary or whatever they can at least read a little 
bit.
I assume you will translate all Spanish or Welsh or .. kernel-oops on 
this mailing-list for non-Spanish-speakers and non-Welsh-speakers.

	Bernd
-- 
Bernd Petrovitsch                              Email : bernd@gams.at
g.a.m.s gmbh                                  Fax : +43 1 205255-900
Prinz-Eugen-Straße 8                    A-1040 Vienna/Austria/Europe
                     LUGA : http://www.luga.at



^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09  9:33   ` Oliver Neukum
@ 2003-04-09 10:24     ` Matti Aarnio
  0 siblings, 0 replies; 137+ messages in thread
From: Matti Aarnio @ 2003-04-09 10:24 UTC (permalink / raw)
  To: Oliver Neukum; +Cc: Frank Davis, linux-kernel

On Wed, Apr 09, 2003 at 11:33:40AM +0200, Oliver Neukum wrote:
> > To propagate the idea further, why not have proper message catalogs,
> >
> > and that way translations.  Instead of:
> > > printk(KERN_WARN "This driver is messed up!\n");
> >
> > There would be:
> >   printk(KERN_WARN "1234-6789 this driver is messed up!\n")
> >
> > In the old days of big iron beasts, there used to be multivolume
> > binders full of system messages, and their explanations.
> > Searching went thru those "1234-5678" strings.
> >
> > There were sets of those manuals in a number of customer languages.
> 
> If we do this, why not go the whole way?
> Could we compute a hash value for every message that's not KERN_CRIT,
> use it to create a table of messages and hashes and replace the messages
> in the kernel image with the hash values leaving expansion to klogd?

  Because hashes  1) change at slightest text changes,  2)  are quite 
  meaningless when a message gets some inserted material, like 
  numbers in them.

  In the big-iron era the messages had 32 ot 64 bit numeric identities
  (or 36 bit in such machines), and were allocated number-spaced by
  each subsystem/product.  E.g.  Assembler had codes 3AFB-**** thru
  3AFF-****,  etc.

  VMS has a bit different style, but how it does exactly do it, I don't
  recall for sure.   %Subsysid-severity-msgid   (or something like that.)

  Presently Linux kernel has just the <severity> code.  Mostly subsysid
  is "kernel", although that could be divided further, so that msgid does
  not need to carry that info, e.g. "kernel-crit-ext3fs_inode_corruption_7"
  instead: "ext3fs-crit-inode_corruption_7"  (or alike).
  The amount of text is .. considerable .. in that kind of styles.

  With:

    printk(msgidcode, KERN_CRIT "mumblemumble", params)

  produced load-time footprint is reduced somewhat.

  Could that come out as:

     <6-MSGID-CODE> mumblemumble...

  Perhaps.  (16+16 bits hex coded should be quite sufficient.
  If some kernel subsystem has over 64 000 messages, things
  are quite bad...)

  Folks at IBM do know how to do things like this.



  Mind you, this WILL NOT help something like  klogd  to translate
  received messages into language XYZ,  merely help administrator
  to find further explanations.

> 	Regards
> 		Oliver

/Matti Aarnio

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09  5:29 ` Oliver Neukum
  2003-04-09  5:50   ` Frank Davis
@ 2003-04-09 11:04   ` Alan Cox
  1 sibling, 0 replies; 137+ messages in thread
From: Alan Cox @ 2003-04-09 11:04 UTC (permalink / raw)
  To: oliver; +Cc: fdavis, Linux Kernel Mailing List

On Mer, 2003-04-09 at 06:29, Oliver Neukum wrote:
> These messages are for administrators and developers. Everybody needs
> to be able to read them. They have to be in English.

Everyone cannot read English. Many non English speakers will be admins
of their own desktop boxes.

For the general case I agree. It would be nice to have message
catalogues and translation capability within klogd and maybe of
a few key messages to console but for most cases it would make things
more complex not simpler


^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-english user messages
  2003-04-09  5:02 kernel support for non-english user messages Frank Davis
                   ` (2 preceding siblings ...)
  2003-04-09  8:08 ` Matti Aarnio
@ 2003-04-09 13:11 ` Giuliano Pochini
  2003-04-10  3:08 ` Linus Torvalds
  4 siblings, 0 replies; 137+ messages in thread
From: Giuliano Pochini @ 2003-04-09 13:11 UTC (permalink / raw)
  To: Frank Davis; +Cc: linux-kernel


On 09-Apr-2003 Frank Davis wrote:
> All,
>
> I wish to suggest a possible 2.6 or 2.7 feature (too late for 2.4.x and
> 2.5.x, I believe) that I believe would be helpful. Currently, printk
> messages are all in english, and I was wondering if printk could be
> modified to print out user messages that are in the default language of
> the machine. For example,
> printk(KERN_WARN "This driver is messed up!\n", getdefaultlanguage());

IMHO the "translation" should be performed at compile time. All those
languages would bloat the kernel image too much.


Bye.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09  8:08 ` Matti Aarnio
  2003-04-09  9:33   ` Oliver Neukum
@ 2003-04-09 22:07   ` Werner Almesberger
  2003-04-09 22:41     ` Frank Davis
  1 sibling, 1 reply; 137+ messages in thread
From: Werner Almesberger @ 2003-04-09 22:07 UTC (permalink / raw)
  To: Matti Aarnio; +Cc: Frank Davis, linux-kernel

Matti Aarnio wrote:
> In the old days of big iron beasts, there used to be multivolume
> binders full of system messages,

... and in the modern age, we have Perl and regexps :-)

Nobody is going to maintain all the translations of "his" component,
so you might as well let the translators try to play catch-up, and
track changes in their regexp database.

For the kernel, we don't have the mechanisms of big companies or
monolithic projects to just funnel all changes of a specific kind
through a single channel, where somebody slaps a unique message-id
on them.

Granted, you can have multi-level messages (like the VMS-style
%facility-severity-ident), but that only buys some time. And you
still either need a message catalog or include the plain text in
the message as well.

The message catalog only approach wouldn't work well for the kernel,
yielding either too many files or patch congestion on central
message files. Think of Documentation/Configure.help and the
relative frequency of changes.

And if you have the (English) plain text, you almost always also
have your unique message key. At least unique enough for
translation. So perhaps it's time to forget the traditional
solutions, and think of a more distributed approach.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09 22:07   ` Werner Almesberger
@ 2003-04-09 22:41     ` Frank Davis
  2003-04-09 22:55       ` Ulrich Drepper
                         ` (2 more replies)
  0 siblings, 3 replies; 137+ messages in thread
From: Frank Davis @ 2003-04-09 22:41 UTC (permalink / raw)
  To: linux-kernel

How about unifying the printk text messages into a limited set of 
common/canned text statements? If that could be done, all that would be 
needed in the kernel would be a small language translation table. The 
output of the table, based on the english input and the user's language 
setting, would be sent to the administrator/user.

On a similar note, Andreas Dilger mentioned this suggestion earlier, 
which it seems has been echoed by others, and that might be agreeable...

"My suggestion would be to add the required i18n support to klogd, so 
that kernel messages are translated as they are removed from dmesg into 
syslog. Then, like any i18n support, you build a message catalog from 
the printk strings in the kernel and have klogd do the 
lookups/translation in user space."

Regards,
Frank


Werner Almesberger wrote:
> Matti Aarnio wrote:
> 
> Nobody is going to maintain all the translations of "his" component,
> so you might as well let the translators try to play catch-up, and
> track changes in their regexp database.
> 
> For the kernel, we don't have the mechanisms of big companies or
> monolithic projects to just funnel all changes of a specific kind
> through a single channel, where somebody slaps a unique message-id
> on them.
> 
> Granted, you can have multi-level messages (like the VMS-style
> %facility-severity-ident), but that only buys some time. And you
> still either need a message catalog or include the plain text in
> the message as well.
> 
> The message catalog only approach wouldn't work well for the kernel,
> yielding either too many files or patch congestion on central
> message files. Think of Documentation/Configure.help and the
> relative frequency of changes.
> 
> And if you have the (English) plain text, you almost always also
> have your unique message key. At least unique enough for
> translation. So perhaps it's time to forget the traditional
> solutions, and think of a more distributed approach.
> 
> - Werner
> 



^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09 22:41     ` Frank Davis
@ 2003-04-09 22:55       ` Ulrich Drepper
  2003-04-09 23:53         ` Johannes Ruscheinski
  2003-04-10  1:43       ` Richard B. Johnson
  2003-04-10  8:19       ` kernel support for non-english user messages Oliver Neukum
  2 siblings, 1 reply; 137+ messages in thread
From: Ulrich Drepper @ 2003-04-09 22:55 UTC (permalink / raw)
  To: fdavis; +Cc: linux-kernel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Davis wrote:

> "My suggestion would be to add the required i18n support to klogd, so
> that kernel messages are translated as they are removed from dmesg into
> syslog. Then, like any i18n support,

This is _not_ like any i18n support.  The problem is that normal
translation support a la gettext or catgets() see the format strings and
not the results.  Translating format strings is easy, translating
results isn't since the translation part has to take the expansion of
the format elements into account.

For numeric format elements this might be possible.  But not without
major problems with %s.  Take hostnames or filenames, which could in
theory contain spaces <U0020>.  You'd have to match using complex
regular expressions.

Another problem is the explosion of messages.  Message lines are often
composed from different sources.  If you see only the end result you'll
have to account for all the different combinations.


I don't say this is impossible, but it is a lot more work, a much more
complex and slower translation mechanism, and (most critical) requires
very strict rules for the creation of messages in the kernel.  I think
the latter point is the killer.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+lKT42ijCOnn/RHQRAlvSAJ9etqgCfTjZ6jZ2M6N+hRY0Hx97AgCeLERp
nPqnFOWpR2s3PuUAuTYfN4E=
=tTfW
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09 22:55       ` Ulrich Drepper
@ 2003-04-09 23:53         ` Johannes Ruscheinski
  0 siblings, 0 replies; 137+ messages in thread
From: Johannes Ruscheinski @ 2003-04-09 23:53 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: fdavis, linux-kernel

Also sprach Ulrich Drepper:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Frank Davis wrote:
> 
> > "My suggestion would be to add the required i18n support to klogd, so
> > that kernel messages are translated as they are removed from dmesg into
> > syslog. Then, like any i18n support,
> 
> This is _not_ like any i18n support.  The problem is that normal
> translation support a la gettext or catgets() see the format strings and
> not the results.  Translating format strings is easy, translating
> results isn't since the translation part has to take the expansion of
> the format elements into account.
> 
> For numeric format elements this might be possible.  But not without
> major problems with %s.  Take hostnames or filenames, which could in
> theory contain spaces <U0020>.  You'd have to match using complex
> regular expressions.
> 
> Another problem is the explosion of messages.  Message lines are often
> composed from different sources.  If you see only the end result you'll
> have to account for all the different combinations.
> 
> 
> I don't say this is impossible, but it is a lot more work, a much more
> complex and slower translation mechanism, and (most critical) requires
> very strict rules for the creation of messages in the kernel.  I think
> the latter point is the killer.
> 
> - -- 
> - --------------.                        ,-.            444 Castro Street
> Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
> Red Hat         `--' drepper at redhat.com `---------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> 
> iD8DBQE+lKT42ijCOnn/RHQRAlvSAJ9etqgCfTjZ6jZ2M6N+hRY0Hx97AgCeLERp
> nPqnFOWpR2s3PuUAuTYfN4E=
> =tTfW
> -----END PGP SIGNATURE-----
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
How about augmenting printk to generate an escape for all numeric format
items.  If we translate into English we just strip out the escapes, otherwise
we use the escapes to translate the numbers appropriately.
-- 
Johannes
--
Dr. Johannes Ruscheinski
EMail:    ruschein_AT_infomine.ucr.edu ***          Linux                  ***
Location: science library, room G40    *** The Choice Of A GNU Generation! ***
Phone:    (909) 787-2279

"SYN -- ACK -- SYN, the mating call of the Internet."
                                         -- Anonymous

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09 22:41     ` Frank Davis
  2003-04-09 22:55       ` Ulrich Drepper
@ 2003-04-10  1:43       ` Richard B. Johnson
  2003-04-10 18:57         ` Alan Cox
  2003-04-10  8:19       ` kernel support for non-english user messages Oliver Neukum
  2 siblings, 1 reply; 137+ messages in thread
From: Richard B. Johnson @ 2003-04-10  1:43 UTC (permalink / raw)
  To: Frank Davis; +Cc: linux-kernel

On Wed, 9 Apr 2003, Frank Davis wrote:

> How about unifying the printk text messages into a limited set of
> common/canned text statements? If that could be done, all that would be
> needed in the kernel would be a small language translation table. The
> output of the table, based on the english input and the user's language
> setting, would be sent to the administrator/user.
>
> On a similar note, Andreas Dilger mentioned this suggestion earlier,
> which it seems has been echoed by others, and that might be agreeable...
[SNIPPED...]

> > Granted, you can have multi-level messages (like the VMS-style
> > %facility-severity-ident), but that only buys some time. And you
> > still either need a message catalog or include the plain text in
> > the message as well.
> >

No. VAX/VMS is dead. It got killed by things like that. Canned
strings that required valuable resources. You don't need any
of that. You need to use the kernel logging facility for the
three or four messages that a properly running system will
issue in its lifetime (like the file-system getting full).

There are too many damn strings in the kernel already. Making
them somehow legitimate is the wrong approach. If there are
so many error messages that we need a translation service, then
there are too many error messages, either because there are too
many errors, or because of the propensity of 'coders' (as opposed
to software engineers) to "print" every *%&$#@&#%_ thing that they
don't understand. Don't get me started, but when was it decided
that you should "print" everything that went okay? I saw during
the past month that somebody wanted to increase the size of
the kernel message ring buffer because they were losing
"important" data. They should fix the errors first before
making new errors. Then, you don't even need printk(). If
they are printing "good" stuff from the kernel, then the
kernel message facility is being abused.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09  5:02 kernel support for non-english user messages Frank Davis
                   ` (3 preceding siblings ...)
  2003-04-09 13:11 ` Giuliano Pochini
@ 2003-04-10  3:08 ` Linus Torvalds
  2003-04-10  9:05   ` kernel support for non-English " Riley Williams
  4 siblings, 1 reply; 137+ messages in thread
From: Linus Torvalds @ 2003-04-10  3:08 UTC (permalink / raw)
  To: linux-kernel

In article <3E93A958.80107@si.rr.com>, Frank Davis  <fdavis@si.rr.com> wrote:
>
>I wish to suggest a possible 2.6 or 2.7 feature (too late for 2.4.x and 
>2.5.x, I believe) that I believe would be helpful. Currently, printk 
>messages are all in english, and I was wondering if printk could be 
>modified to print out user messages that are in the default language of 
>the machine. For example,

This has come up before.

The answer is: go ahead and do it, but don't do it in the kernel. Do it
in klogd or similar.

I refuse to clutter the kernel with inane and fragile (and totally
unmaintainable) internationalization code. The string lookup can equally
well be done in user space where it isn't a stability and complexity
issue.

		Linus

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09 22:41     ` Frank Davis
  2003-04-09 22:55       ` Ulrich Drepper
  2003-04-10  1:43       ` Richard B. Johnson
@ 2003-04-10  8:19       ` Oliver Neukum
  2 siblings, 0 replies; 137+ messages in thread
From: Oliver Neukum @ 2003-04-10  8:19 UTC (permalink / raw)
  To: fdavis, linux-kernel

Am Donnerstag, 10. April 2003 00:41 schrieb Frank Davis:
> How about unifying the printk text messages into a limited set of
> common/canned text statements? If that could be done, all that would be
> needed in the kernel would be a small language translation table. The
> output of the table, based on the english input and the user's language
> setting, would be sent to the administrator/user.

This is a nightmare to keep current.

> On a similar note, Andreas Dilger mentioned this suggestion earlier,
> which it seems has been echoed by others, and that might be agreeable...
>
> "My suggestion would be to add the required i18n support to klogd, so
> that kernel messages are translated as they are removed from dmesg into
> syslog. Then, like any i18n support, you build a message catalog from
> the printk strings in the kernel and have klogd do the
> lookups/translation in user space."

The strings are too variable. The kernel embeds strings into some of
its messages. There must be hints in the output about what should
be translated and what must be left alone.
Like:
<esc>xxxxxxxxDummyfs: Unknown flags for file <lit>myfile

That means that you have to parse and mangle the strings as they
are in the kernel sources: "Dummyfs: Unknown flags for file %s\n"
This is not very difficult, printk() does it already. The beauty of that
would be that "Dummyfs: Unknown flags for file" now strictly speaking
is unnecessary in the kernel image. The mangling tool can replace it
with a number which klogd can replace with the original.
However this means that kernel and 'messages file' need to be kept
in sync, like System.map currently.

Now that is not all. Klogd will not run in some cases and cannot
be assumed to always run in others. Eg klogd itself may oops or the
drive with the messages file may break down, or we might be booting.
You might remove the strings only for KERN_DEBUG and KERN_INFO
strings. That should result in space savings and translation ability.

	Regards
		Oliver


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-10  3:08 ` Linus Torvalds
@ 2003-04-10  9:05   ` Riley Williams
  2003-04-10 17:35     ` Linus Torvalds
  0 siblings, 1 reply; 137+ messages in thread
From: Riley Williams @ 2003-04-10  9:05 UTC (permalink / raw)
  To: Linus Torvalds, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]

Hi Linus.

 >> I wish to suggest a possible 2.6 or 2.7 feature (too late for
 >> 2.4.x and 2.5.x, I believe) that I believe would be helpful.
 >> Currently, printk messages are all in English, and I was
 >> wondering if printk could be modified to print out user
 >> messages that are in the default language of the machine.

 > This has come up before.
 >
 > The answer is: go ahead and do it, but don't do it in the kernel.
 > Do it in klogd or similar.
 >
 > I refuse to clutter the kernel with inane and fragile (and totally
 > unmaintainable) internationalization code. The string lookup can
 > equally well be done in user space where it isn't a stability and
 > complexity issue.

Whilst I agree with the general sentiments above, any such code would
require some sort of code attached to each message for it to look up,
with the standard English message tagged on to the end for systems
where the translation code isn't in use.

At the moment, printk() calls are supposed to have a string along the
lines of "<2>" prepended onto each line. Can I ask whether you have
any objection in principle to this being changed to something along
the lines of <2:xxxx> where the xxxx is a code to enable translation
systems to index that message?

This would probably require the current macros used to prepend the
relevant string to be changed to macro functions such that...

	printk(KERN_ERR "Sample error message.\n");

...would become...

	printk(KERN_NO(KERN_NO_ERR,"1234") "Sample error message.\n");

...and would result in...

	"<3:1234>Sample error message.\n"

...being printed out. The change of macro name is specifically for
backwards compatibility, and the resulting system would allow the
actual messages to be changed over time rather than all at once.

If this is acceptable, then the patch to make all relevant changes
against the 2.5.67 kernel tree is attached. This patch assigns the
message number 0000 to all current messages, thus reserving that
number as "Not yet numbered" as far as translation software is
concerned.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.470 / Virus Database: 268 - Release Date: 8-Apr-2003

[-- Attachment #2: Linux-Logging-2.5.67.diff --]
[-- Type: application/octet-stream, Size: 1781 bytes --]

--- include/linux/kernel.h~	Mon Apr  7 18:30:33 2003
+++ include/linux/kernel.h	Thu Apr 10 09:58:13 2003
@@ -29,18 +29,29 @@
 #define STACK_MAGIC	0xdeadbeef
 
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 #define ALIGN(x,a) (((x)+(a)-1)&~((a)-1))
 
-#define	KERN_EMERG	"<0>"	/* system is unusable			*/
+#define	KERN_NO_EMERG	"0"	/* system is unusable			*/
-#define	KERN_ALERT	"<1>"	/* action must be taken immediately	*/
+#define	KERN_NO_ALERT	"1"	/* action must be taken immediately	*/
-#define	KERN_CRIT	"<2>"	/* critical conditions			*/
+#define	KERN_NO_CRIT	"2"	/* critical conditions			*/
-#define	KERN_ERR	"<3>"	/* error conditions			*/
+#define	KERN_NO_ERR	"3"	/* error conditions			*/
-#define	KERN_WARNING	"<4>"	/* warning conditions			*/
+#define	KERN_NO_WARNING	"4"	/* warning conditions			*/
-#define	KERN_NOTICE	"<5>"	/* normal but significant condition	*/
+#define	KERN_NO_NOTICE	"5"	/* normal but significant condition	*/
-#define	KERN_INFO	"<6>"	/* informational			*/
+#define	KERN_NO_INFO	"6"	/* informational			*/
-#define	KERN_DEBUG	"<7>"	/* debug-level messages			*/
+#define	KERN_NO_DEBUG	"7"	/* debug-level messages			*/
+
+#define	KERN_NO(x,y)	"<" x ":" y ">"
+
+#define	KERN_EMERG	KERN_NO(KERN_NO_EMERG,  "0000")
+#define	KERN_ALERT	KERN_NO(KERN_NO_ALERT,  "0000")
+#define	KERN_CRIT	KERN_NO(KERN_NO_CRIT,   "0000")
+#define	KERN_ERR	KERN_NO(KERN_NO_ERR,    "0000")
+#define	KERN_WARNING	KERN_NO(KERN_NO_WARNING,"0000")
+#define	KERN_NOTICE	KERN_NO(KERN_NO_NOTICE, "0000")
+#define	KERN_INFO	KERN_NO(KERN_NO_INFO,   "0000")
+#define	KERN_DEBUG	KERN_NO(KERN_NO_DEBUG,  "0000")
 
 extern int console_printk[];
 
 #define console_loglevel (console_printk[0])
 #define default_message_loglevel (console_printk[1])

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-10  9:05   ` kernel support for non-English " Riley Williams
@ 2003-04-10 17:35     ` Linus Torvalds
  2003-04-10 18:32       ` John Bradford
  2003-04-12  2:55       ` Chris Wedgwood
  0 siblings, 2 replies; 137+ messages in thread
From: Linus Torvalds @ 2003-04-10 17:35 UTC (permalink / raw)
  To: Riley Williams; +Cc: linux-kernel


On Thu, 10 Apr 2003, Riley Williams wrote:
> 
> Whilst I agree with the general sentiments above, any such code would
> require some sort of code attached to each message for it to look up,

No.

I've used VMS, and error code number encoding is a total heap of crap.

If you can't translate the message based on the _message_, then don't
bother. I'm not adding codes for different errors, it becomes just an
unreadable mess, and adds _zero_ to stability or readability, and it's
horrible for maintenance - suddenly you need to worry about silly numbers
for anything you print out, so you stop printing stuff or you re-use codes
that don't make sense.

The road to hell is paved with good intentions. This is one of those "good 
intentions" things - it sounds like it's a nice helper thing, but it's 
nothing but a load of maintenance headaches and causes horrible printout 
headaches.

		Linus


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-10 17:35     ` Linus Torvalds
@ 2003-04-10 18:32       ` John Bradford
  2003-04-12  2:55       ` Chris Wedgwood
  1 sibling, 0 replies; 137+ messages in thread
From: John Bradford @ 2003-04-10 18:32 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Riley Williams, linux-kernel

> The road to hell is paved with good intentions. This is one of those "good 
> intentions" things - it sounds like it's a nice helper thing, but it's 
> nothing but a load of maintenance headaches and causes horrible printout 
> headaches.

The best option might be simply to document things like error messages
in more detail, (and translate that documentation into as many
languages as possible).

For example, when the IDE code started outputting debug info for a
feature that wasn't implemented on a lot of older drives, (around
2.4.20), there were _loads_ of posts asking what the error meant, and
whether it was something to worry about - a simple

printk ("This is not a critical error");

would have saved a lot of time :-), (note, this isn't a criticism of
the IDE maintainers - it's not practical, or helpful to make _every_
error message verbose, but if it had been documented somewhere, it
would have been useful).

I suggest we introduce a 'grepme' file in the top level of the kernel
source distribution which, as the name suggests, is the first place to
look for whatever-you-were-going-to-post-to-LKML-about.  I volunteer
to maintain such a 'grepme' file if you'll aprove the idea, Linus?

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10  1:43       ` Richard B. Johnson
@ 2003-04-10 18:57         ` Alan Cox
  2003-04-10 20:13           ` Trond Myklebust
  2003-04-10 20:36           ` John Bradford
  0 siblings, 2 replies; 137+ messages in thread
From: Alan Cox @ 2003-04-10 18:57 UTC (permalink / raw)
  To: root; +Cc: Frank Davis, Linux Kernel Mailing List

On Thu, 2003-04-10 at 02:43, Richard B. Johnson wrote:
> No. VAX/VMS is dead. It got killed by things like that. Canned
> strings that required valuable resources. You don't need any
> of that. You need to use the kernel logging facility for the
> three or four messages that a properly running system will
> issue in its lifetime (like the file-system getting full).

VMS is alive and well, even though Compaq tried to kill it. There is 
a lot of anti-VMS stuff in the Unix world mostly coming from the
_horrible_ command line and other bad early memories. There is 
also a hell of a lot of really cool stuff under that command line
we could and should learn from.

Alan


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 20:13           ` Trond Myklebust
@ 2003-04-10 19:42             ` Alan Cox
  2003-04-11  0:48               ` Christer Weinigel
  2003-04-10 20:53             ` Richard B. Johnson
  1 sibling, 1 reply; 137+ messages in thread
From: Alan Cox @ 2003-04-10 19:42 UTC (permalink / raw)
  To: Trond Myklebust; +Cc: root, Frank Davis, Linux Kernel Mailing List

On Thu, 2003-04-10 at 21:13, Trond Myklebust wrote:
> The day I wake up and see one of my processes in the "RWAST" state is
> the day I move to a BSD clone 8-)

The AST stuff was a bit buggy yes

> Which features in particular were you thinking would be worth porting?

Give me the clustering support 8)


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 18:57         ` Alan Cox
@ 2003-04-10 20:13           ` Trond Myklebust
  2003-04-10 19:42             ` Alan Cox
  2003-04-10 20:53             ` Richard B. Johnson
  2003-04-10 20:36           ` John Bradford
  1 sibling, 2 replies; 137+ messages in thread
From: Trond Myklebust @ 2003-04-10 20:13 UTC (permalink / raw)
  To: Alan Cox; +Cc: root, Frank Davis, Linux Kernel Mailing List

>>>>> " " == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

     > VMS is alive and well, even though Compaq tried to kill
     > it. There is a lot of anti-VMS stuff in the Unix world mostly
     > coming from the _horrible_ command line and other bad early
     > memories. There is also a hell of a lot of really cool stuff
     > under that command line we could and should learn from.

The day I wake up and see one of my processes in the "RWAST" state is
the day I move to a BSD clone 8-)

Which features in particular were you thinking would be worth porting?

Cheers,
 Trond

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 18:57         ` Alan Cox
  2003-04-10 20:13           ` Trond Myklebust
@ 2003-04-10 20:36           ` John Bradford
  2003-04-10 22:20             ` Shaya Potter
  2003-04-24 23:25             ` versioned filesystems in linux (was Re: kernel support for non-english user messages) Stewart Smith
  1 sibling, 2 replies; 137+ messages in thread
From: John Bradford @ 2003-04-10 20:36 UTC (permalink / raw)
  To: Alan Cox; +Cc: root, Frank Davis, Linux Kernel Mailing List

> There is a lot of anti-VMS stuff in the Unix world mostly coming
> from the _horrible_ command line and other bad early memories. There
> is also a hell of a lot of really cool stuff under that command line
> we could and should learn from.

When are we going to see versioned filesystems in Linux?  That was a
standard feature in VMS.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 20:13           ` Trond Myklebust
  2003-04-10 19:42             ` Alan Cox
@ 2003-04-10 20:53             ` Richard B. Johnson
  2003-04-10 23:05               ` Jon Portnoy
  2003-04-11 11:57               ` Helge Hafting
  1 sibling, 2 replies; 137+ messages in thread
From: Richard B. Johnson @ 2003-04-10 20:53 UTC (permalink / raw)
  To: Trond Myklebust; +Cc: Alan Cox, Frank Davis, Linux Kernel Mailing List

On Thu, 10 Apr 2003, Trond Myklebust wrote:

> >>>>> " " == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>
>      > VMS is alive and well, even though Compaq tried to kill
>      > it. There is a lot of anti-VMS stuff in the Unix world mostly
>      > coming from the _horrible_ command line and other bad early
>      > memories. There is also a hell of a lot of really cool stuff
>      > under that command line we could and should learn from.
>
> The day I wake up and see one of my processes in the "RWAST" state is
> the day I move to a BSD clone 8-)
>
> Which features in particular were you thinking would be worth porting?
>
> Cheers,
>  Trond
>

Once a year I get up enough nerve to boot my VAXen at home. One
is a uVAX-II which even has SCSI with some DEC snail disks.
The uVAX-II takes about 45 to 50 minutes to boot and it's really
quite amazing to watch it do all that difficult stuff, with all
its intermediate progress messages being written to the screen
when it's booting VMS.

But sometimes, just for kicks, I boot Ultrix (Unix) on the second
drive. It takes only 4 minutes and doesn't waste time with all
those "progress" messages. Now, Linux has already gotten to
be like VMS with all those "progress" messages displayed while
it's booting. It's really quite annoying, and it scares the
hell out of users that are graduating from Windows. Anything
that further legitimizes those progress messages (like translation)
should never be implemented.

When somebody is writing a driver, if they have any experience,
they write debugging messages in their native language. But, once
the driver is written, these debugging messages should be removed
or #defined out. A properly functioning driver should never complain
about anything. It shouldn't do anything like you see when you
execute `dmesg`. The only time you should see information is
if there's trouble. And trouble with software should be fixed
immediately so you never have to encounter messages because software
didn't work. So, you are left will hardware messages like your
SCSI disk didn't come on-line, or you are out of disk-space.
For so few messages, you don't need translation, certainly not
in the kernel. Just Babel-fish it and away you go.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 20:36           ` John Bradford
@ 2003-04-10 22:20             ` Shaya Potter
  2003-04-11  4:19               ` Valdis.Kletnieks
  2003-04-24 23:25             ` versioned filesystems in linux (was Re: kernel support for non-english user messages) Stewart Smith
  1 sibling, 1 reply; 137+ messages in thread
From: Shaya Potter @ 2003-04-10 22:20 UTC (permalink / raw)
  To: John Bradford; +Cc: Alan Cox, root, Frank Davis, Linux Kernel Mailing List

On Thu, 2003-04-10 at 16:36, John Bradford wrote:
> > There is a lot of anti-VMS stuff in the Unix world mostly coming
> > from the _horrible_ command line and other bad early memories. There
> > is also a hell of a lot of really cool stuff under that command line
> > we could and should learn from.
> 
> When are we going to see versioned filesystems in Linux?  That was a
> standard feature in VMS.

it shouldn't be that hard, it was one of the 6 OS projects for the
regular 4000 level (senior/grad) level OS class here at columbia last
semster.  

The assignment was to modify ext2 to support versioning, basically means
making a copy of it within ext2's open, if it's opened O_RDWR.  The
assignment was a little bit more complicated in that we took an ext2
flag bit to mean "version", so that a file would only be versioned if
the bit was set, as well as only allowing a single level of versioning,
though extending it w/ more wouldn't be that hard.

The student solutions (as well as our sample solution) weren't that
"pretty", but then again, each project was only for 2-2.5 weeks.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 20:53             ` Richard B. Johnson
@ 2003-04-10 23:05               ` Jon Portnoy
  2003-04-11  5:39                 ` DevilKin
  2003-04-11 11:57               ` Helge Hafting
  1 sibling, 1 reply; 137+ messages in thread
From: Jon Portnoy @ 2003-04-10 23:05 UTC (permalink / raw)
  To: Richard B. Johnson; +Cc: Linux Kernel Mailing List

[CC list trimmed, it was getting ridiculous]

On Thu, 10 Apr 2003, Richard B. Johnson wrote:

> On Thu, 10 Apr 2003, Trond Myklebust wrote:
> 
> > >>>>> " " == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> >
[snip]
> 
> When somebody is writing a driver, if they have any experience,
> they write debugging messages in their native language. But, once
> the driver is written, these debugging messages should be removed
> or #defined out. A properly functioning driver should never complain
> about anything. It shouldn't do anything like you see when you
> execute `dmesg`. The only time you should see information is
> if there's trouble. And trouble with software should be fixed
> immediately so you never have to encounter messages because software
> didn't work. So, you are left will hardware messages like your
> SCSI disk didn't come on-line, or you are out of disk-space.
> For so few messages, you don't need translation, certainly not
> in the kernel. Just Babel-fish it and away you go.
> 

A whole lot of users use dmesg output to figure out if their kernel is 
detecting a piece of hardware. That's a very useful thing to have handy 
and definitely not something that should be yanked out for the sake of 
making it look pretty for people who don't know what they're doing with 
their computer.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 19:42             ` Alan Cox
@ 2003-04-11  0:48               ` Christer Weinigel
  2003-04-11 15:56                 ` Daniel Stekloff
  0 siblings, 1 reply; 137+ messages in thread
From: Christer Weinigel @ 2003-04-11  0:48 UTC (permalink / raw)
  To: Alan Cox; +Cc: Trond Myklebust, root, Frank Davis, Linux Kernel Mailing List

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Thu, 2003-04-10 at 21:13, Trond Myklebust wrote:
> > Which features in particular were you thinking would be worth porting?
> 
> Give me the clustering support 8)

One of the things I really liked with VMS was the centralized logging
in a clustered system.  I'd very much like to be able to say "give me
all syslog messages for the mail subsystem at this severity level or
above" instead of having to play around with /etc/syslog.conf,
restarting syslogd and tail -f.  Of course this isn't a kernel
problem, it's something that should be implemented in syslog, but it's
just an example of a good idea in VMS.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 22:20             ` Shaya Potter
@ 2003-04-11  4:19               ` Valdis.Kletnieks
  2003-04-11  4:23                 ` Shaya Potter
                                   ` (2 more replies)
  0 siblings, 3 replies; 137+ messages in thread
From: Valdis.Kletnieks @ 2003-04-11  4:19 UTC (permalink / raw)
  To: Shaya Potter
  Cc: John Bradford, Alan Cox, root, Frank Davis, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 3790 bytes --]

On Thu, 10 Apr 2003 18:20:15 EDT, Shaya Potter said:
> On Thu, 2003-04-10 at 16:36, John Bradford wrote:
> > > There is a lot of anti-VMS stuff in the Unix world mostly coming
> > > from the _horrible_ command line and other bad early memories. There
> > > is also a hell of a lot of really cool stuff under that command line
> > > we could and should learn from.
> > 
> > When are we going to see versioned filesystems in Linux?  That was a
> > standard feature in VMS.
> 
> it shouldn't be that hard, it was one of the 6 OS projects for the
> regular 4000 level (senior/grad) level OS class here at columbia last
> semster.  
> 
> The assignment was to modify ext2 to support versioning, basically means
> making a copy of it within ext2's open, if it's opened O_RDWR.  The
> assignment was a little bit more complicated in that we took an ext2
> flag bit to mean "version", so that a file would only be versioned if
> the bit was set, as well as only allowing a single level of versioning,
> though extending it w/ more wouldn't be that hard.
> 
> The student solutions (as well as our sample solution) weren't that
> "pretty", but then again, each project was only for 2-2.5 weeks.

The problem is, as usual, in the details that almost never get handled in 2-week
student projects.  Some off the top of my head:

1) What happens when *multiple* programs have a file open at the same time?
If you only handle one level of versioning, somebody is going to lose.  Handling
multiple levels is of course more "fun".  And you get to worry about race
conditions - does your code DTRT if multiple processes do an open() on alternate
CPUs at the same time.  Does it DTRT if a process open()s a file, and then fork()s,
and both parent and child start scribbling on the file descriptor?

2) For that matter, should new versions be created at open() or at the first write()?
Doing it at write() allows not creating a new version if no changes have
actually happened - but this has its own issues.  

3) Version a 500 megabyte file.  Change one block.  Do it a few more times.
Are you better off copying the whole file (which bloats your disk usage and
kills your I/O bandwidth), or keeping deltas (the list of allocated blocks could be
almost identical except for the replaced/rewritten blocks).  However, this DOES
make doing an fsck() a *lot* more interesting - is a block allocated to multiple
files in error or not?

4) What happens if you rename() a file?  Can you open() a previous version for
writing?  If so, does it get versioned?  How does a backup program restore a
previous version?

5) Let's say we use VMS-style filenames to version.  foo, foo;2, foo;3, etc.
Now, is open("foo;2",...) a reference to the previous version of foo or to a new
file that happens to be called foo;2?  What happens if some other file happens
to be called foo;2 and you create a version  of foo?

6) OK, since anything besides \0 and / is legal in a filename, we can't use ;N to
version.  Let's steal another field in the inode to do the counting.  Now how does
userspace reference a previous version easily?  Can you get into a situation where
different versions of a file have different owners/permissions?

7) Userspace support.  Anybody want to open that can and take up worm farming? ;)

8) User support issues.  See (7). ;)

That's just the first 10 minutes or so of thinking about things that could be problems
that a student project won't address.

Yes, VMS had to worry about a lot of these issues too - but VMS had the advantage that
versioning was designed into the environment from very early on, and wasn't a retrofit
as it would be for Linux.  So they could make arbitrary rules like "If there's a
;nnn on the end of a filename, it's a version" without having to worry about breaking
anything.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-11  4:19               ` Valdis.Kletnieks
@ 2003-04-11  4:23                 ` Shaya Potter
  2003-04-11  8:40                   ` Henning P. Schmiedehausen
  2003-04-11  9:09                 ` John Bradford
  2003-04-11 11:40                 ` Helge Hafting
  2 siblings, 1 reply; 137+ messages in thread
From: Shaya Potter @ 2003-04-11  4:23 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: John Bradford, Alan Cox, root, Frank Davis, Linux Kernel Mailing List

yes, yes.  I of course agree, just saying that if someone really wanted
to do it, banging out a skeleton solution that can be filled in
shouldn't be "that" hard.  Getting it "right"(tm) would be tougher, but
I think doable.  The reason I think no one has done it, is because no
one is really that interested.

On Fri, 2003-04-11 at 00:19, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 10 Apr 2003 18:20:15 EDT, Shaya Potter said:
> > On Thu, 2003-04-10 at 16:36, John Bradford wrote:
> > > > There is a lot of anti-VMS stuff in the Unix world mostly coming
> > > > from the _horrible_ command line and other bad early memories. There
> > > > is also a hell of a lot of really cool stuff under that command line
> > > > we could and should learn from.
> > > 
> > > When are we going to see versioned filesystems in Linux?  That was a
> > > standard feature in VMS.
> > 
> > it shouldn't be that hard, it was one of the 6 OS projects for the
> > regular 4000 level (senior/grad) level OS class here at columbia last
> > semster.  
> > 
> > The assignment was to modify ext2 to support versioning, basically means
> > making a copy of it within ext2's open, if it's opened O_RDWR.  The
> > assignment was a little bit more complicated in that we took an ext2
> > flag bit to mean "version", so that a file would only be versioned if
> > the bit was set, as well as only allowing a single level of versioning,
> > though extending it w/ more wouldn't be that hard.
> > 
> > The student solutions (as well as our sample solution) weren't that
> > "pretty", but then again, each project was only for 2-2.5 weeks.
> 
> The problem is, as usual, in the details that almost never get handled in 2-week
> student projects.  Some off the top of my head:
> 
> 1) What happens when *multiple* programs have a file open at the same time?
> If you only handle one level of versioning, somebody is going to lose.  Handling
> multiple levels is of course more "fun".  And you get to worry about race
> conditions - does your code DTRT if multiple processes do an open() on alternate
> CPUs at the same time.  Does it DTRT if a process open()s a file, and then fork()s,
> and both parent and child start scribbling on the file descriptor?
> 
> 2) For that matter, should new versions be created at open() or at the first write()?
> Doing it at write() allows not creating a new version if no changes have
> actually happened - but this has its own issues.  
> 
> 3) Version a 500 megabyte file.  Change one block.  Do it a few more times.
> Are you better off copying the whole file (which bloats your disk usage and
> kills your I/O bandwidth), or keeping deltas (the list of allocated blocks could be
> almost identical except for the replaced/rewritten blocks).  However, this DOES
> make doing an fsck() a *lot* more interesting - is a block allocated to multiple
> files in error or not?
> 
> 4) What happens if you rename() a file?  Can you open() a previous version for
> writing?  If so, does it get versioned?  How does a backup program restore a
> previous version?
> 
> 5) Let's say we use VMS-style filenames to version.  foo, foo;2, foo;3, etc.
> Now, is open("foo;2",...) a reference to the previous version of foo or to a new
> file that happens to be called foo;2?  What happens if some other file happens
> to be called foo;2 and you create a version  of foo?
> 
> 6) OK, since anything besides \0 and / is legal in a filename, we can't use ;N to
> version.  Let's steal another field in the inode to do the counting.  Now how does
> userspace reference a previous version easily?  Can you get into a situation where
> different versions of a file have different owners/permissions?
> 
> 7) Userspace support.  Anybody want to open that can and take up worm farming? ;)
> 
> 8) User support issues.  See (7). ;)
> 
> That's just the first 10 minutes or so of thinking about things that could be problems
> that a student project won't address.
> 
> Yes, VMS had to worry about a lot of these issues too - but VMS had the advantage that
> versioning was designed into the environment from very early on, and wasn't a retrofit
> as it would be for Linux.  So they could make arbitrary rules like "If there's a
> ;nnn on the end of a filename, it's a version" without having to worry about breaking
> anything.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 23:05               ` Jon Portnoy
@ 2003-04-11  5:39                 ` DevilKin
  2003-04-11  5:49                   ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 137+ messages in thread
From: DevilKin @ 2003-04-11  5:39 UTC (permalink / raw)
  To: Jon Portnoy, Richard B. Johnson; +Cc: Linux Kernel Mailing List, devilkin-lkml

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 11 April 2003 01:05, Jon Portnoy wrote:
> A whole lot of users use dmesg output to figure out if their kernel is
> detecting a piece of hardware. That's a very useful thing to have handy
> and definitely not something that should be yanked out for the sake of
> making it look pretty for people who don't know what they're doing with
> their computer.

True. 

Why not turn it into a kernel flag that you can set at bootup through LILO or 
some other obscure boot manager? Then you could boot linux like this:

linux dmesg=verbose

and

linux dmesg=quiet

with any of the two being the default setting. This way you can have the cake 
and eat it too: the verbose setting for those that want it, and the quiet 
setting for the users that don't want to get scared sh*tless everytime their 
system boots. I know I got scared first time I booted a Linux box :P

Jan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+llUapuyeqyCEh60RAoQiAJ482mlR4GYiagB3r05dDRaYtJfWJACfSow4
qO0z3Q68S5TRoUqENlB/Asc=
=tMBA
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-11  5:39                 ` DevilKin
@ 2003-04-11  5:49                   ` Arnaldo Carvalho de Melo
  2003-04-11  6:17                     ` DevilKin
  2003-04-11 17:51                     ` Randy.Dunlap
  0 siblings, 2 replies; 137+ messages in thread
From: Arnaldo Carvalho de Melo @ 2003-04-11  5:49 UTC (permalink / raw)
  To: DevilKin; +Cc: Jon Portnoy, Richard B. Johnson, Linux Kernel Mailing List

Em Fri, Apr 11, 2003 at 07:39:35AM +0200, DevilKin escreveu:
> Why not turn it into a kernel flag that you can set at bootup through LILO or 
> some other obscure boot manager? Then you could boot linux like this:
> 
> linux dmesg=verbose
> 
> and
> 
> linux dmesg=quiet

Have you ever tried passing 'quiet' as a cmd line parameter to the kernel
in the bootloader? If not please try.

Try also 'debug'.

- Arnaldo

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-11  5:49                   ` Arnaldo Carvalho de Melo
@ 2003-04-11  6:17                     ` DevilKin
  2003-04-11 17:51                     ` Randy.Dunlap
  1 sibling, 0 replies; 137+ messages in thread
From: DevilKin @ 2003-04-11  6:17 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo; +Cc: linux-kernel, Devilkin-lkml

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 11 April 2003 07:49, Arnaldo Carvalho de Melo wrote:
> Have you ever tried passing 'quiet' as a cmd line parameter to the kernel
> in the bootloader? If not please try.
>
> Try also 'debug'.
>

I had actually no idea that existed. Sorry about my rather useless posting 
then. Might be interesting to move some of the current dmesg messages to the 
debug stage - some output is really way to detailed to be in the standard 
output...

Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD4DBQE+ll33puyeqyCEh60RAglnAJ9gNQHwCO5ZabnHsKnx46xsdKMfJwCWNNrC
rbmZ2A+26NYCIU+k8YU+2Q==
=PuPi
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-11  4:23                 ` Shaya Potter
@ 2003-04-11  8:40                   ` Henning P. Schmiedehausen
  0 siblings, 0 replies; 137+ messages in thread
From: Henning P. Schmiedehausen @ 2003-04-11  8:40 UTC (permalink / raw)
  To: linux-kernel

Shaya Potter <spotter@cs.columbia.edu> writes:

>yes, yes.  I of course agree, just saying that if someone really wanted
>to do it, banging out a skeleton solution that can be filled in
>shouldn't be "that" hard.  Getting it "right"(tm) would be tougher, but
>I think doable.  The reason I think no one has done it, is because no
>one is really that interested.

The main problem of open source software development and open source
programming is, that most developers bang out a cool "skeleton
solution" or a "two weeks project" and after that, hope that some
volunteers will fill up the spaces that they left when they turned to
the next "cool skeleton solution".

Thats' why 90+% of the project on sf are dead and of the rest, most
are in a "beta" state.

	Regards
		Henning
-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-11  4:19               ` Valdis.Kletnieks
  2003-04-11  4:23                 ` Shaya Potter
@ 2003-04-11  9:09                 ` John Bradford
  2003-04-11 10:59                   ` Valdis.Kletnieks
  2003-04-11 11:40                 ` Helge Hafting
  2 siblings, 1 reply; 137+ messages in thread
From: John Bradford @ 2003-04-11  9:09 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: Shaya Potter, John Bradford, Alan Cox, root, Frank Davis,
	Linux Kernel Mailing List

> 
> --==_Exmh_1967715762P
> Content-Type: text/plain; charset=us-ascii
> 
> On Thu, 10 Apr 2003 18:20:15 EDT, Shaya Potter said:
> > On Thu, 2003-04-10 at 16:36, John Bradford wrote:
> > > > There is a lot of anti-VMS stuff in the Unix world mostly coming
> > > > from the _horrible_ command line and other bad early memories. There
> > > > is also a hell of a lot of really cool stuff under that command line
> > > > we could and should learn from.
> > > 
> > > When are we going to see versioned filesystems in Linux?  That was a
> > > standard feature in VMS.
> > 
> > it shouldn't be that hard, it was one of the 6 OS projects for the
> > regular 4000 level (senior/grad) level OS class here at columbia last
> > semster.  
> > 
> > The assignment was to modify ext2 to support versioning, basically means
> > making a copy of it within ext2's open, if it's opened O_RDWR.  The
> > assignment was a little bit more complicated in that we took an ext2
> > flag bit to mean "version", so that a file would only be versioned if
> > the bit was set, as well as only allowing a single level of versioning,
> > though extending it w/ more wouldn't be that hard.
> > 
> > The student solutions (as well as our sample solution) weren't that
> > "pretty", but then again, each project was only for 2-2.5 weeks.
> 
> The problem is, as usual, in the details that almost never get handled in 2-week
> student projects.  Some off the top of my head:
> 
> 1) What happens when *multiple* programs have a file open at the
> same time? 
> If you only handle one level of versioning, somebody is going to
> lose.  Handling multiple levels is of course more "fun".  And you
> get to worry about race conditions - does your code DTRT if multiple
> processes do an open() on alternate CPUs at the same time.  Does it
> DTRT if a process open()s a file, and then fork()s, and both parent
> and child start scribbling on the file descriptor?

This would almost certainly require extra permission bits to decide
what happens.

> 2) For that matter, should new versions be created at open() or at
> the first write()?
> Doing it at write() allows not creating a new version if no changes have
> actually happened - but this has its own issues.

No, I think it should be done at open().

> 3) Version a 500 megabyte file.  Change one block.  Do it a few more
> times.  Are you better off copying the whole file (which bloats your
> disk usage and kills your I/O bandwidth), or keeping deltas (the
> list of allocated blocks could be almost identical except for the
> replaced/rewritten blocks).  However, this DOES make doing an fsck()
> a *lot* more interesting - is a block allocated to multiple files in
> error or not?

I'd say copy the whole file, it's not going to be any worse than
somebody manually doing cp current_version old_version; vi
current_version, although as it makes the process more automatic, it
might be happening more frequently.

> 4) What happens if you rename() a file?  Can you open() a previous
> version for writing?  If so, does it get versioned?  How does a
> backup program restore a previous version?

There need to be extra permission bits for this, but you could have
old versions default to read-only, and possibly have a flag for,
"modified from the real version foo", or even store an MD5 sum of each
version, that way if the original was replaced, it could be detected
and clear that flag.

> 5) Let's say we use VMS-style filenames to version.  foo, foo;2,
> foo;3, etc. 
> Now, is open("foo;2",...) a reference to the previous version of foo
> or to a new file that happens to be called foo;2?  What happens if
> some other file happens to be called foo;2 and you create a version
> of foo?
> 
> 6) OK, since anything besides \0 and / is legal in a filename, we
> can't use ;N to version.  Let's steal another field in the inode to
> do the counting.  Now how does userspace reference a previous
> version easily?  Can you get into a situation where different
> versions of a file have different owners/permissions?

A versioned file becomes openable as a directory as well, so that you
can see the old versions.  I'm sure something like this has already
been done, I'll have to try to search it out.

> 7) Userspace support.  Anybody want to open that can and take up
> worm farming? ;)
> 
> 8) User support issues.  See (7). ;)

Might not be such a big problem if we use the directory idea.

> That's just the first 10 minutes or so of thinking about things that
> could be problems that a student project won't address.
> 
> Yes, VMS had to worry about a lot of these issues too - but VMS had
> the advantage that versioning was designed into the environment from
> very early on, and wasn't a retrofit as it would be for Linux.  So
> they could make arbitrary rules like "If there's a ;nnn on the end
> of a filename, it's a version" without having to worry about
> breaking anything.

I thought ISO9660 had versioning?  How do we handle that, (if at all)?

I totally agree that it would be a retrofit in to Linux, but how many
modern OSes support versioning?

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-11  9:09                 ` John Bradford
@ 2003-04-11 10:59                   ` Valdis.Kletnieks
  2003-04-11 11:11                     ` John Bradford
  0 siblings, 1 reply; 137+ messages in thread
From: Valdis.Kletnieks @ 2003-04-11 10:59 UTC (permalink / raw)
  To: John Bradford
  Cc: Shaya Potter, Alan Cox, root, Frank Davis, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

On Fri, 11 Apr 2003 10:09:44 BST, John Bradford said:

> A versioned file becomes openable as a directory as well, so that you
> can see the old versions.  I'm sure something like this has already
> been done, I'll have to try to search it out.

There was "Hidden Directory" support in IBM's AIX/370 (and probably the
AIX 1.2 that was i386-only), and I'm told some of the HP Apollo stuff
did similar.  Very strange, bizzare, aggrivating, and occasionally useful.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-11 10:59                   ` Valdis.Kletnieks
@ 2003-04-11 11:11                     ` John Bradford
  0 siblings, 0 replies; 137+ messages in thread
From: John Bradford @ 2003-04-11 11:11 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: John Bradford, Shaya Potter, Alan Cox, root, Frank Davis,
	Linux Kernel Mailing List

> > A versioned file becomes openable as a directory as well, so that you
> > can see the old versions.  I'm sure something like this has already
> > been done, I'll have to try to search it out.
> 
> There was "Hidden Directory" support in IBM's AIX/370 (and probably the
> AIX 1.2 that was i386-only), and I'm told some of the HP Apollo stuff
> did similar.  Very strange, bizzare, aggrivating, and occasionally useful.

Well, you can say that about almost any feature, but you can always
compile it out :-).

A versioned filesystem would be very useful for:

* Webservers
* Development of small projects, where you don't need the overhead of
  an SCM, but something similar is useful.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-11  4:19               ` Valdis.Kletnieks
  2003-04-11  4:23                 ` Shaya Potter
  2003-04-11  9:09                 ` John Bradford
@ 2003-04-11 11:40                 ` Helge Hafting
  2 siblings, 0 replies; 137+ messages in thread
From: Helge Hafting @ 2003-04-11 11:40 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Linux Kernel Mailing List

Valdis.Kletnieks@vt.edu wrote:

> 1) What happens when *multiple* programs have a file open at the same time?
> If you only handle one level of versioning, somebody is going to lose.  Handling
Sure -which is why this isn't so useful.

> multiple levels is of course more "fun".  And you get to worry about race
> conditions - does your code DTRT if multiple processes do an open() on alternate
> CPUs at the same time.  Does it DTRT if a process open()s a file, and then fork()s,
> and both parent and child start scribbling on the file descriptor?
> 
> 2) For that matter, should new versions be created at open() or at the first write()?
> Doing it at write() allows not creating a new version if no changes have
> actually happened - but this has its own issues.  
> 
Simple solution - duplicate at open() but remove on close() if unchanged.

> 3) Version a 500 megabyte file.  Change one block.  Do it a few more times.
> Are you better off copying the whole file (which bloats your disk usage and
> kills your I/O bandwidth), or keeping deltas (the list of allocated blocks could be
> almost identical except for the replaced/rewritten blocks).  However, this DOES
> make doing an fsck() a *lot* more interesting - is a block allocated to multiple
> files in error or not?
> 
If you want this, you want a copy-on-write fs.  Of course it needs a
different fsck.

> 4) What happens if you rename() a file?  
It is renamed - nothing special there.  Renaming onto an existing file
makes the renamed file the most recent version of that file.
"mv foo;2 foo" turns foo;2 into the current version - this is one
way of restoring an old version without deleting the newer ones.

> Can you open() a previous version for
> writing?  If so, does it get versioned?  How does a backup program restore a
> previous version?

VMS let you open() any previous version for writing. I don't remember 
exactly,
but I believe this creates a new version with a version number higher 
than the
highest existing version of the file.  Either that, or you modify the 
old file.

Backup is not a problem.  You don't want to create new versions while 
restoring,
so either remove existing files before recreating from backup (You
can then explicitly create "file.txt;45") or implement some open flag
that means "use exactly this filename - no messing with versioning" I 
think the
first approach is better  it keeps the interface smaller.

> 5) Let's say we use VMS-style filenames to version.  foo, foo;2, foo;3, etc.
> Now, is open("foo;2",...) a reference to the previous version of foo or to a new
> file that happens to be called foo;2?  What happens if some other file happens
> to be called foo;2 and you create a version  of foo?
> 
I remember trying this. If foo;3 exists (but not foo;2 and lower) then
the numbering of new versions go upwards and simply skips the existing ones.

> 6) OK, since anything besides \0 and / is legal in a filename, we can't use ;N to
> version.  
We can if we want to - by redefining whats legal.  This isn't a problem 
at all
if we take the approach that opening "foo" does the versioning automatically
while explicitly opening "foo;x" opens that particular version.  Users 
creating
a "fake" version of a file isn't a problem - they simply created a new 
version
that happened to not be based on the contents of the previous one.

Helge Hafting


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 20:53             ` Richard B. Johnson
  2003-04-10 23:05               ` Jon Portnoy
@ 2003-04-11 11:57               ` Helge Hafting
  2003-04-11 17:55                 ` David Lang
  1 sibling, 1 reply; 137+ messages in thread
From: Helge Hafting @ 2003-04-11 11:57 UTC (permalink / raw)
  To: root; +Cc: linux-kernel

Richard B. Johnson wrote:

> But sometimes, just for kicks, I boot Ultrix (Unix) on the second
> drive. It takes only 4 minutes and doesn't waste time with all
> those "progress" messages. Now, Linux has already gotten to
> be like VMS with all those "progress" messages displayed while
> it's booting. It's really quite annoying,
There are several ways to get rid of them - I lost all
once when using a unsupported framebuffer.  No messages
at all until X came up.

> and it scares the
> hell out of users that are graduating from Windows.

Couldn't care less about the scaring part.  Linux is different,
otherwise why try it?  So they better expect some differences
and get used to them.  Scared - bah!

Much user interface work can be done on easing the transition, but
this is not one of those cases.  Because people just don't
need to deal with those messages unless there's a crash.  And then
they get time enough to read the frozen display, and
the details _will_ be useful.

> Anything
> that further legitimizes those progress messages (like translation)
> should never be implemented.
> 
> When somebody is writing a driver, if they have any experience,
> they write debugging messages in their native language. But, once
> the driver is written, these debugging messages should be removed
> or #defined out. A properly functioning driver should never complain
> about anything. 

It shouldn't complain, but I see no problem with the driver
saying "ok, found 3 scsi adapers and 8 disks"  This is
particularly useful if I expected it to find all 4 adapters.
The driver saw no problem but I still did.

> It shouldn't do anything like you see when you
> execute `dmesg`.

Get used to it.  Linux scroll some pages of text at bootup - so what?
Of course you _can_ configure it away if you want to, or get your
linux from a distributor that do.  It is more interesting than
watching a blank screen and wondering "what takes so much time?"
With linux I see that - it lets me optimize, for example by
dropping support for nonexisting hardware that have long
probe timeouts.  This sort of thing isn't for "everybody",
but even windows people enjoy optimizing their machines a bit now and then.

Helge Hafting


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-11  0:48               ` Christer Weinigel
@ 2003-04-11 15:56                 ` Daniel Stekloff
  0 siblings, 0 replies; 137+ messages in thread
From: Daniel Stekloff @ 2003-04-11 15:56 UTC (permalink / raw)
  To: Christer Weinigel, Alan Cox
  Cc: Trond Myklebust, root, Frank Davis, Linux Kernel Mailing List

On Thursday 10 April 2003 05:48 pm, Christer Weinigel wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > On Thu, 2003-04-10 at 21:13, Trond Myklebust wrote:
> > > Which features in particular were you thinking would be worth porting?
> >
> > Give me the clustering support 8)
>
> One of the things I really liked with VMS was the centralized logging
> in a clustered system.  I'd very much like to be able to say "give me
> all syslog messages for the mail subsystem at this severity level or
> above" instead of having to play around with /etc/syslog.conf,
> restarting syslogd and tail -f.  Of course this isn't a kernel
> problem, it's something that should be implemented in syslog, but it's
> just an example of a good idea in VMS.


Are you familar with IBM's Event Logging? 

http://evlog.sourceforge.net/

Event Logging works well in a clustered environment. You can have your logs go 
to one central location and, with the help of a plug-in, you could dump the 
messages off into a database for easy queries. Mark Megerian at IBM is 
working with a DB2 plug-in. Here's the thread on the evlog mailing list:

http://sourceforge.net/mailarchive/forum.php?thread_id=1785428&forum_id=659

Thanks,

Dan


>   /Christer


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-11  5:49                   ` Arnaldo Carvalho de Melo
  2003-04-11  6:17                     ` DevilKin
@ 2003-04-11 17:51                     ` Randy.Dunlap
  1 sibling, 0 replies; 137+ messages in thread
From: Randy.Dunlap @ 2003-04-11 17:51 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo; +Cc: devilkin-lkml, portnoy, root, linux-kernel

On Fri, 11 Apr 2003 02:49:32 -0300 Arnaldo Carvalho de Melo <acme@conectiva.com.br> wrote:

| Em Fri, Apr 11, 2003 at 07:39:35AM +0200, DevilKin escreveu:
| > Why not turn it into a kernel flag that you can set at bootup through LILO or 
| > some other obscure boot manager? Then you could boot linux like this:
| > 
| > linux dmesg=verbose
| > 
| > and
| > 
| > linux dmesg=quiet
| 
| Have you ever tried passing 'quiet' as a cmd line parameter to the kernel
| in the bootloader? If not please try.
| 
| Try also 'debug'.

I use 'debug' all the time, but then some init script comes along and
changes the loglevel setting to something < debug.  Ick.


--
~Randy   ['tangent' is not a verb...unless you believe that
          "in English any noun can be verbed."]

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-11 11:57               ` Helge Hafting
@ 2003-04-11 17:55                 ` David Lang
  0 siblings, 0 replies; 137+ messages in thread
From: David Lang @ 2003-04-11 17:55 UTC (permalink / raw)
  To: Helge Hafting; +Cc: root, linux-kernel

On Fri, 11 Apr 2003, Helge Hafting wrote:

> Richard B. Johnson wrote:
> >
> > When somebody is writing a driver, if they have any experience,
> > they write debugging messages in their native language. But, once
> > the driver is written, these debugging messages should be removed
> > or #defined out. A properly functioning driver should never complain
> > about anything.
>
> It shouldn't complain, but I see no problem with the driver
> saying "ok, found 3 scsi adapers and 8 disks"  This is
> particularly useful if I expected it to find all 4 adapters.
> The driver saw no problem but I still did.
>

the problem is one of noise, while it is sometimes useful to see these
messages (back when I was a PC tech working on windows systems I kept a
set of slackware disks handy to boot from and see what hardware was really
installed in the machines before hunting for the windows drivers) we are
also getting to a point where so many things are flashing by on the screen
that it's very hard to see them (especially with todays nice fast
machines).

it's like network Intrusion Detection systems, a lot of people install
them and gain no value from them becouse they send out so many alerts that
they get ignored.

I definantly don't want the verbose mode to go away, but it may be time to
make the default be the quiet mode that only prints actual errors instead
of the current verbosity.

David Lang

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-10 17:35     ` Linus Torvalds
  2003-04-10 18:32       ` John Bradford
@ 2003-04-12  2:55       ` Chris Wedgwood
  1 sibling, 0 replies; 137+ messages in thread
From: Chris Wedgwood @ 2003-04-12  2:55 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Riley Williams, linux-kernel

On Thu, Apr 10, 2003 at 10:35:36AM -0700, Linus Torvalds wrote:

> I've used VMS, and error code number encoding is a total heap of
> crap.

What about prefixing known messages with error-numbers, perhaps even
being able to suppress these for sysctl or similar?  Would that not
work both-ways?

The only thing is that it requires more work in the build process...


  --cw

^ permalink raw reply	[flat|nested] 137+ messages in thread

* versioned filesystems in linux (was Re: kernel support for non-english user messages)
  2003-04-10 20:36           ` John Bradford
  2003-04-10 22:20             ` Shaya Potter
@ 2003-04-24 23:25             ` Stewart Smith
  2003-04-25  7:14               ` John Bradford
  2003-04-25 15:20               ` Matthew Sell
  1 sibling, 2 replies; 137+ messages in thread
From: Stewart Smith @ 2003-04-24 23:25 UTC (permalink / raw)
  To: John Bradford; +Cc: Alan Cox, root, Frank Davis, Linux Kernel Mailing List

On Friday, April 11, 2003, at 06:36  AM, John Bradford wrote:
> When are we going to see versioned filesystems in Linux?  That was a
> standard feature in VMS.

This is (part of) what I'm doing for my honors project this year - so 
possibly something (might) be around and (almost) working by the end of 
the year. The real big trick is remote efficiency - but what's the fun 
of research if there isn't something tricky?

If people are actually really interested in it, I might make it a bit 
more of a focus :)

More info avail on request :)
------------------------------
Stewart Smith
stewartsmith@mac.com
Ph: +61 4 3884 4332
ICQ: 6734154


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: versioned filesystems in linux (was Re: kernel support for non-english user messages)
  2003-04-24 23:25             ` versioned filesystems in linux (was Re: kernel support for non-english user messages) Stewart Smith
@ 2003-04-25  7:14               ` John Bradford
  2003-04-25 15:20               ` Matthew Sell
  1 sibling, 0 replies; 137+ messages in thread
From: John Bradford @ 2003-04-25  7:14 UTC (permalink / raw)
  To: Stewart Smith
  Cc: Alan Cox, root, Frank Davis, Linux Kernel Mailing List, John Bradford

> > When are we going to see versioned filesystems in Linux?  That was a
> > standard feature in VMS.
> 
> This is (part of) what I'm doing for my honors project this year - so 
> possibly something (might) be around and (almost) working by the end of 
> the year. The real big trick is remote efficiency - but what's the fun 
> of research if there isn't something tricky?
> 
> If people are actually really interested in it, I might make it a bit 
> more of a focus :)

I'm certainly interested in it.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: versioned filesystems in linux (was Re: kernel support for non-english user messages)
  2003-04-24 23:25             ` versioned filesystems in linux (was Re: kernel support for non-english user messages) Stewart Smith
  2003-04-25  7:14               ` John Bradford
@ 2003-04-25 15:20               ` Matthew Sell
  2003-04-25 15:45                 ` Richard B. Johnson
  1 sibling, 1 reply; 137+ messages in thread
From: Matthew Sell @ 2003-04-25 15:20 UTC (permalink / raw)
  To: Stewart Smith, Linux Kernel Mailing List

Stewart Smith wrote:

> On Friday, April 11, 2003, at 06:36  AM, John Bradford wrote:
>
>> When are we going to see versioned filesystems in Linux?  That was a
>> standard feature in VMS.
>
>
> This is (part of) what I'm doing for my honors project this year - so 
> possibly something (might) be around and (almost) working by the end 
> of the year. The real big trick is remote efficiency - but what's the 
> fun of research if there isn't something tricky?
>
> If people are actually really interested in it, I might make it a bit 
> more of a focus :)
>
> More info avail on request :)


It would be nice to see what assistance the FreeVMS group may be able to 
offer. It appears that they are attempting to make an operating system 
compatible with VMS based on the Linux kernel.

 From what I have observed, a few of them seem to have extensive 
experience with VMS and may be able to offer at least some baseline 
knowledge as to how VMS accomplishes this.

My curiosity lies with the ability to run FreeVMS on VAX....

(Why not? It's just a hobby....)


    - Matt



-- 

-------------------------
Matthew Sell
Programmer
UNIX System Administrator
On Time Support, Inc.
www.ontimesupport.com

Join the Metrology Software Discussion List METLIST!
www.ontimesupport.com/subscribe_t&c.html


AIX - Linux - NetBSD - OpenVMS - Solaris

Expand Your Horizons - Stop Looking Through Windows



^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: versioned filesystems in linux (was Re: kernel support for non-english user messages)
  2003-04-25 15:20               ` Matthew Sell
@ 2003-04-25 15:45                 ` Richard B. Johnson
  2003-04-25 16:18                   ` versioned filesystems in linux (was Re: kernel support for John Bradford
  0 siblings, 1 reply; 137+ messages in thread
From: Richard B. Johnson @ 2003-04-25 15:45 UTC (permalink / raw)
  To: Matthew Sell; +Cc: Stewart Smith, Linux Kernel Mailing List

On Fri, 25 Apr 2003, Matthew Sell wrote:

> Stewart Smith wrote:
>
> > On Friday, April 11, 2003, at 06:36  AM, John Bradford wrote:
> >
> >> When are we going to see versioned filesystems in Linux?  That was a
> >> standard feature in VMS.
> >
> >
> > This is (part of) what I'm doing for my honors project this year - so
> > possibly something (might) be around and (almost) working by the end
> > of the year. The real big trick is remote efficiency - but what's the
> > fun of research if there isn't something tricky?
> >
> > If people are actually really interested in it, I might make it a bit
> > more of a focus :)
> >
> > More info avail on request :)
>
>
> It would be nice to see what assistance the FreeVMS group may be able to
> offer. It appears that they are attempting to make an operating system
> compatible with VMS based on the Linux kernel.
>
>  From what I have observed, a few of them seem to have extensive
> experience with VMS and may be able to offer at least some baseline
> knowledge as to how VMS accomplishes this.
>
> My curiosity lies with the ability to run FreeVMS on VAX....
>
> (Why not? It's just a hobby....)
>
>
>     - Matt
>

Good grief!  Versioning is just a file-naming convention!

MISSING;0
MISSING;1
MISSING;3
MISSING;4
Makefile;0
Makefile;1
Makefile;3
bufio.c;9
bufio.c;10
bufio.c;11
bufio.o;0
checker;0
checker.c;0
checker.c;1
checker.c;2
checker.o;0

You just modify your user-mode tools and your 'C' runtime library
to make whatever atrocious versioning mechanism you want. You can
even make all filenames upper case, just like VAX/VMS, and you can
even make your shell DCL if you want. It's where the rules are
enforced like (mapping everything to upper-case).

I can see it now, upon startup `init` execs:

   SYS$SYSTEM:LOGINOUT.EXE -
   INPUT=SYS$SYSTEM:[etc]inittab -
   OUTPUT=SYS$SYSTEM:[var.log]startup.log -
   ERROR=SYS$SYSTEM:[dev]console -
   UIC=[0,0] -
   PRIV=(NOALL, TMPMBX, NETMBX, SETPRV)


Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: versioned filesystems in linux (was Re: kernel support for
  2003-04-25 15:45                 ` Richard B. Johnson
@ 2003-04-25 16:18                   ` John Bradford
  2003-04-25 17:06                     ` Richard B. Johnson
  0 siblings, 1 reply; 137+ messages in thread
From: John Bradford @ 2003-04-25 16:18 UTC (permalink / raw)
  To: root; +Cc: Matthew Sell, Stewart Smith, Linux Kernel Mailing List

> You just modify your user-mode tools and your 'C' runtime library
> to make whatever atrocious versioning mechanism you want. You can
> even make all filenames upper case, just like VAX/VMS, and you can
> even make your shell DCL if you want. It's where the rules are
> enforced like (mapping everything to upper-case).
> 
> I can see it now, upon startup `init` execs:
> 
>    SYS$SYSTEM:LOGINOUT.EXE -
>    INPUT=SYS$SYSTEM:[etc]inittab -
>    OUTPUT=SYS$SYSTEM:[var.log]startup.log -
>    ERROR=SYS$SYSTEM:[dev]console -
>    UIC=[0,0] -
>    PRIV=(NOALL, TMPMBX, NETMBX, SETPRV)

Just wondering how difficult it would be to make a 9-track tape drive
from scratch, and connect it up to the parallel port...  Do you think
that old hard disk motors, from 5.25" MFM disks be powerful enough for
the 120IPS tape transport?

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: versioned filesystems in linux (was Re: kernel support for
  2003-04-25 16:18                   ` versioned filesystems in linux (was Re: kernel support for John Bradford
@ 2003-04-25 17:06                     ` Richard B. Johnson
  2003-04-25 17:48                       ` Valdis.Kletnieks
  2003-04-25 18:13                       ` versioned filesystems in linux (was Re: kernel support for John Bradford
  0 siblings, 2 replies; 137+ messages in thread
From: Richard B. Johnson @ 2003-04-25 17:06 UTC (permalink / raw)
  To: John Bradford; +Cc: Matthew Sell, Stewart Smith, Linux Kernel Mailing List

On Fri, 25 Apr 2003, John Bradford wrote:

> > You just modify your user-mode tools and your 'C' runtime library
> > to make whatever atrocious versioning mechanism you want. You can
> > even make all filenames upper case, just like VAX/VMS, and you can
> > even make your shell DCL if you want. It's where the rules are
> > enforced like (mapping everything to upper-case).
> >
> > I can see it now, upon startup `init` execs:
> >
> >    SYS$SYSTEM:LOGINOUT.EXE -
> >    INPUT=SYS$SYSTEM:[etc]inittab -
> >    OUTPUT=SYS$SYSTEM:[var.log]startup.log -
> >    ERROR=SYS$SYSTEM:[dev]console -
> >    UIC=[0,0] -
> >    PRIV=(NOALL, TMPMBX, NETMBX, SETPRV)
>
> Just wondering how difficult it would be to make a 9-track tape drive
> from scratch, and connect it up to the parallel port...  Do you think
> that old hard disk motors, from 5.25" MFM disks be powerful enough for
> the 120IPS tape transport?
>
> John.

The disk-drive motors, even for the 5.25 floppies were pancake motors
designed to directly turn the floppy, or run a belt with a small
ratio. You need a motor that runs at relatively high speed to turn the
capstan. If the capstan was 1 inch in circumference (about 0.2'' in
diameter), you need 120 revs/sec = 7200 r.p.m.  You won't do this with
a floppy motor.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: versioned filesystems in linux (was Re: kernel support for
  2003-04-25 17:06                     ` Richard B. Johnson
@ 2003-04-25 17:48                       ` Valdis.Kletnieks
  2003-04-25 19:38                         ` H. Peter Anvin
  2003-04-25 18:13                       ` versioned filesystems in linux (was Re: kernel support for John Bradford
  1 sibling, 1 reply; 137+ messages in thread
From: Valdis.Kletnieks @ 2003-04-25 17:48 UTC (permalink / raw)
  To: root; +Cc: Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 2516 bytes --]

On Fri, 25 Apr 2003 13:06:18 EDT, "Richard B. Johnson" said:
> On Fri, 25 Apr 2003, John Bradford wrote:

> > Just wondering how difficult it would be to make a 9-track tape drive
> > from scratch, and connect it up to the parallel port...  Do you think
> > that old hard disk motors, from 5.25" MFM disks be powerful enough for
> > the 120IPS tape transport?
> >
> > John.
> 
> The disk-drive motors, even for the 5.25 floppies were pancake motors
> designed to directly turn the floppy, or run a belt with a small
> ratio. You need a motor that runs at relatively high speed to turn the
> capstan. If the capstan was 1 inch in circumference (about 0.2'' in
> diameter), you need 120 revs/sec = 7200 r.p.m.  You won't do this with
> a floppy motor.

It's not that bad, actually - the capstan is more like 4 inches across, and the
minimum actual diameter of the tape is about 6 inches, giving a circumference
of 18" so you only need about 400RPM at the "empty" reel and maybe half that at
the "full" reel.

(More than you ever wanted to know about old tape drives, probably ;)

Of bigger concern is that the inter-block gap is only 0.5 (or maybe 0.75
inches, the memories are dim ;) - and you need to be able to stop and then get
back up to speed in that distance (or decelerate, rewind, and get a running
start).  This was why the IBM3420 (and predecessor) tape drives had vacuum
columns - there'd be a loop of up to 5-6 feet in a column on each side of the
head.  To move the tape for a single block, it would increase suction on one
column, causing the tape to be pulled in, and reduce it in the other, feeding
tape out.  Since the weight of the 6-10 feet of tape being moved is low,
acceleration is quite fast - a 3420 doesn't stream continuously, and it's QUITE
possible to be writing short blocks (80 bytes or so at 6250 bytes per inch,
which results in an actual block of about half an inch) where the tape stops,
accelerates, writes, stops, etc.. and still maintain 200 inches per second
throughput (yes, the vacuum columns ARE emitting a 200hz square wave sound when
you do this - programs have been done to play music by using different block
sizes...)

The actual capstans would then have several foot of buffering to get up to
speed (or stop), which was needed as the rotational inertia of a full 2400 foot
9 track tape is *not* trivial.  Low-end 9-track transports did a cheaper
version of this, using 2 tension arms and a drive motor near the head, similar
to audiophile reel-to-reel tape transports.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: versioned filesystems in linux (was Re: kernel support for
  2003-04-25 17:06                     ` Richard B. Johnson
  2003-04-25 17:48                       ` Valdis.Kletnieks
@ 2003-04-25 18:13                       ` John Bradford
  2003-04-25 18:34                         ` Richard B. Johnson
  1 sibling, 1 reply; 137+ messages in thread
From: John Bradford @ 2003-04-25 18:13 UTC (permalink / raw)
  To: root
  Cc: John Bradford, Matthew Sell, Stewart Smith, Linux Kernel Mailing List

> > Just wondering how difficult it would be to make a 9-track tape drive
> > from scratch, and connect it up to the parallel port...  Do you think
> > that old hard disk motors, from 5.25" MFM disks be powerful enough for
> > the 120IPS tape transport?
> 
> The disk-drive motors, even for the 5.25 floppies were pancake motors
> designed to directly turn the floppy, or run a belt with a small
> ratio. You need a motor that runs at relatively high speed to turn the
> capstan. If the capstan was 1 inch in circumference (about 0.2'' in
> diameter), you need 120 revs/sec = 7200 r.p.m.  You won't do this with
> a floppy motor.

I was thinking of hard disk motors...  Actually, some of those would
be 3600 r.p.m., so if we used a large capstan, we might be in with a
chance :-).  (You'd really need to drive the actual reels as well,
though, I can't see us starting and stopping the whole thing very
quickly just using the capstan motor.)

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: versioned filesystems in linux (was Re: kernel support for
  2003-04-25 18:13                       ` versioned filesystems in linux (was Re: kernel support for John Bradford
@ 2003-04-25 18:34                         ` Richard B. Johnson
  0 siblings, 0 replies; 137+ messages in thread
From: Richard B. Johnson @ 2003-04-25 18:34 UTC (permalink / raw)
  To: John Bradford; +Cc: Matthew Sell, Stewart Smith, Linux Kernel Mailing List

On Fri, 25 Apr 2003, John Bradford wrote:

> > > Just wondering how difficult it would be to make a 9-track tape drive
> > > from scratch, and connect it up to the parallel port...  Do you think
> > > that old hard disk motors, from 5.25" MFM disks be powerful enough for
> > > the 120IPS tape transport?
> >
> > The disk-drive motors, even for the 5.25 floppies were pancake motors
> > designed to directly turn the floppy, or run a belt with a small
> > ratio. You need a motor that runs at relatively high speed to turn the
> > capstan. If the capstan was 1 inch in circumference (about 0.2'' in
> > diameter), you need 120 revs/sec = 7200 r.p.m.  You won't do this with
> > a floppy motor.
>
> I was thinking of hard disk motors...  Actually, some of those would
> be 3600 r.p.m., so if we used a large capstan, we might be in with a
> chance :-).  (You'd really need to drive the actual reels as well,
> though, I can't see us starting and stopping the whole thing very
> quickly just using the capstan motor.)
>
> John.
>

Oh the hard-disk motor that drive the RA80 will rotate the
building if it ever stalled. I understand that the mechanical
designers for that make vacuum cleaners right out of college.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: versioned filesystems in linux (was Re: kernel support for
  2003-04-25 17:48                       ` Valdis.Kletnieks
@ 2003-04-25 19:38                         ` H. Peter Anvin
  2003-04-25 21:21                           ` 9-track tape drive (Was: Re: versioned filesystems in linux) John Bradford
  0 siblings, 1 reply; 137+ messages in thread
From: H. Peter Anvin @ 2003-04-25 19:38 UTC (permalink / raw)
  To: linux-kernel

Followup to:  <200304251748.h3PHmjQd012895@turing-police.cc.vt.edu>
By author:    Valdis.Kletnieks@vt.edu
In newsgroup: linux.dev.kernel
> 
> Of bigger concern is that the inter-block gap is only 0.5 (or maybe 0.75
> inches, the memories are dim ;) - and you need to be able to stop and then get
> back up to speed in that distance (or decelerate, rewind, and get a running
> start).
> 

No, you don't.  You just need to make sure you don't have the head
active while you overshoot.  Performance will *definitely* suffer if
you don't, though, since you'd have to rewind.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

^ permalink raw reply	[flat|nested] 137+ messages in thread

* 9-track tape drive (Was: Re: versioned filesystems in linux)
  2003-04-25 19:38                         ` H. Peter Anvin
@ 2003-04-25 21:21                           ` John Bradford
  2003-04-25 21:22                             ` H. Peter Anvin
  0 siblings, 1 reply; 137+ messages in thread
From: John Bradford @ 2003-04-25 21:21 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: linux-kernel

> > Of bigger concern is that the inter-block gap is only 0.5 (or maybe 0.75
> > inches, the memories are dim ;) - and you need to be able to stop and then get
> > back up to speed in that distance (or decelerate, rewind, and get a running
> > start).
> > 
> 
> No, you don't.  You just need to make sure you don't have the head
> active while you overshoot.  Performance will *definitely* suffer if
> you don't, though, since you'd have to rewind.

Well, we could make our device dual speed, and either run at E.G. 60
I.P.S. or 120 I.P.S. depending on whether we want to read a large
block of data, or just one block that happens to be closer to the
current head position than the distance we need to accellerate to 120
I.P.S.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: 9-track tape drive (Was: Re: versioned filesystems in linux)
  2003-04-25 21:21                           ` 9-track tape drive (Was: Re: versioned filesystems in linux) John Bradford
@ 2003-04-25 21:22                             ` H. Peter Anvin
  2003-04-25 21:31                               ` Mike Dresser
  0 siblings, 1 reply; 137+ messages in thread
From: H. Peter Anvin @ 2003-04-25 21:22 UTC (permalink / raw)
  To: John Bradford; +Cc: linux-kernel

John Bradford wrote:
>>>Of bigger concern is that the inter-block gap is only 0.5 (or maybe 0.75
>>>inches, the memories are dim ;) - and you need to be able to stop and then get
>>>back up to speed in that distance (or decelerate, rewind, and get a running
>>>start).
>>>
>>
>>No, you don't.  You just need to make sure you don't have the head
>>active while you overshoot.  Performance will *definitely* suffer if
>>you don't, though, since you'd have to rewind.
> 
> 
> Well, we could make our device dual speed, and either run at E.G. 60
> I.P.S. or 120 I.P.S. depending on whether we want to read a large
> block of data, or just one block that happens to be closer to the
> current head position than the distance we need to accellerate to 120
> I.P.S.
> 

Actually, as long as you get enough read speed across the head and can
actually measure the real speed you can presumably vary the speed
arbitrarily, all the way up to the breaking point of the medium.

	-hpa



^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: 9-track tape drive (Was: Re: versioned filesystems in linux)
  2003-04-25 21:22                             ` H. Peter Anvin
@ 2003-04-25 21:31                               ` Mike Dresser
  2003-04-26  6:32                                 ` H. Peter Anvin
  0 siblings, 1 reply; 137+ messages in thread
From: Mike Dresser @ 2003-04-25 21:31 UTC (permalink / raw)
  To: linux-kernel

On Fri, 25 Apr 2003, H. Peter Anvin wrote:

> actually measure the real speed you can presumably vary the speed
> arbitrarily, all the way up to the breaking point of the medium.

I suspect that method is patented, as I have seen this implemented on
both Travan tapes, and cassette tapes.

However, there seems to have been a flaw in the implementation, where the
breaking point was underestimated.

Mike


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: 9-track tape drive (Was: Re: versioned filesystems in linux)
  2003-04-25 21:31                               ` Mike Dresser
@ 2003-04-26  6:32                                 ` H. Peter Anvin
  2003-04-26  6:57                                   ` John Bradford
  0 siblings, 1 reply; 137+ messages in thread
From: H. Peter Anvin @ 2003-04-26  6:32 UTC (permalink / raw)
  To: linux-kernel

Followup to:  <Pine.LNX.4.33.0304251729490.18442-100000@router.windsormachine.com>
By author:    Mike Dresser <mdresser_l@windsormachine.com>
In newsgroup: linux.dev.kernel
>
> On Fri, 25 Apr 2003, H. Peter Anvin wrote:
> 
> > actually measure the real speed you can presumably vary the speed
> > arbitrarily, all the way up to the breaking point of the medium.
> 
> I suspect that method is patented, as I have seen this implemented on
> both Travan tapes, and cassette tapes.
> 
> However, there seems to have been a flaw in the implementation, where the
> breaking point was underestimated.
> 

Presumably any patents on this have since long expired (they would
have had to have been filed no earlier than 1983.)

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: 9-track tape drive (Was: Re: versioned filesystems in linux)
  2003-04-26  6:32                                 ` H. Peter Anvin
@ 2003-04-26  6:57                                   ` John Bradford
  0 siblings, 0 replies; 137+ messages in thread
From: John Bradford @ 2003-04-26  6:57 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: linux-kernel

> > > actually measure the real speed you can presumably vary the speed
> > > arbitrarily, all the way up to the breaking point of the medium.
> > 
> > I suspect that method is patented, as I have seen this implemented on
> > both Travan tapes, and cassette tapes.
> > 
> > However, there seems to have been a flaw in the implementation, where the
> > breaking point was underestimated.
> > 
> 
> Presumably any patents on this have since long expired (they would
> have had to have been filed no earlier than 1983.)

Using two heads, you should be able to write at variable speed as well
- if the heads are spaced two blocks apart, whatever speed you read a
block at with the first head, you could write the new data using the
second head at the same speed.

As long as the tape is formatted correctly, it should work.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-17 15:07         ` Randolph Bentson
@ 2003-04-17 18:49           ` Eric Altendorf
  0 siblings, 0 replies; 137+ messages in thread
From: Eric Altendorf @ 2003-04-17 18:49 UTC (permalink / raw)
  To: Randolph Bentson; +Cc: linux-kernel

On Thursday 17 April 2003 08:07, Randolph Bentson wrote:
>
> That's true if documentation serves only to describe _what_ the
> code does.  You've ignored the need to describe _why_ the code
> was written in this way.  For example, documentation can note some
> feature of the hardware which requires special handling, or it can
> describe some emergent property which isn't obvious even if all
> the code is understood.
>
> That's why local comments should explain non-obvious trickery used,
> perhaps the exploitation of a poorly documented side-effect of some
> instruction, and block comments or external documentation should
> help the reader understand why things are done some particular way.
> For instance, if the code implements some specific, well documented
> algorithm, it should reference the algorithm by name.

You're right; this is very true.  I suppose I overlooked that due to 
my background in other kinds of code bases...  In an "ideal" code 
base, written from scratch, you'd probably need very very few 
comments.  If you're interfacing with buggy legacy code or 
problematic hardware, I can see there'd be a much greater need.

Eric

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-15 18:02       ` Eric Altendorf
  2003-04-17 13:46         ` Alan Cox
@ 2003-04-17 15:07         ` Randolph Bentson
  2003-04-17 18:49           ` Eric Altendorf
  1 sibling, 1 reply; 137+ messages in thread
From: Randolph Bentson @ 2003-04-17 15:07 UTC (permalink / raw)
  To: Eric Altendorf; +Cc: linux-kernel

On Tue, Apr 15, 2003 at 11:02:15AM -0700, Eric Altendorf wrote:
> If you find yourself having to write comments and documentation to 
> explain your code, probably your identifiers are not well named, your 
> functions are not short enough, and your code is not well structured 
> enough.
> 
> Ideal code is completely self-documenting.

That's true if documentation serves only to describe _what_ the
code does.  You've ignored the need to describe _why_ the code
was written in this way.  For example, documentation can note some
feature of the hardware which requires special handling, or it can
describe some emergent property which isn't obvious even if all
the code is understood.

That's why local comments should explain non-obvious trickery used,
perhaps the exploitation of a poorly documented side-effect of some
instruction, and block comments or external documentation should
help the reader understand why things are done some particular way.
For instance, if the code implements some specific, well documented
algorithm, it should reference the algorithm by name.

-- 
Randolph Bentson
bentson@holmsjoen.com

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-15 18:02       ` Eric Altendorf
@ 2003-04-17 13:46         ` Alan Cox
  2003-04-17 15:07         ` Randolph Bentson
  1 sibling, 0 replies; 137+ messages in thread
From: Alan Cox @ 2003-04-17 13:46 UTC (permalink / raw)
  To: EricAltendorf
  Cc: Linus Torvalds, John Bradford, vda, Chuck Ebbert,
	Linux Kernel Mailing List

On Maw, 2003-04-15 at 19:02, Eric Altendorf wrote:
> If you find yourself having to write comments and documentation to 
> explain your code, probably your identifiers are not well named, your 
> functions are not short enough, and your code is not well structured 
> enough.
> 
> Ideal code is completely self-documenting.

We have a lot of elegant small functions that require knowledge of
the data structures and lock ordering, which is why I do go around
sticking kernel-doc into stuff I touch. 

Explaining the function is one thing, explaining the context in which
it operates is another [IMHO]


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-16 18:34         ` Timothy Miller
@ 2003-04-16 18:37           ` Bruce Harada
  0 siblings, 0 replies; 137+ messages in thread
From: Bruce Harada @ 2003-04-16 18:37 UTC (permalink / raw)
  To: Timothy Miller; +Cc: linux-kernel

On Wed, 16 Apr 2003 14:34:44 -0400
Timothy Miller <miller@techsource.com> wrote:

> >Well, it rather depends on the person... try setting your locale to
> >ja_JP.eucJP, and you might be surprised by the applications that give you
> >Japanese messages. Certainly, some Japanese people prefer messages in
> >English, but that can hardly be generalized across the entire userbase.
> >  
> >
> Applications.  Far more people work on applications than on the kernel.

Just to clarify, by 'applications' I meant things like make and gcc ;)

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-16 17:04       ` Bruce Harada
@ 2003-04-16 18:34         ` Timothy Miller
  2003-04-16 18:37           ` Bruce Harada
  0 siblings, 1 reply; 137+ messages in thread
From: Timothy Miller @ 2003-04-16 18:34 UTC (permalink / raw)
  To: Bruce Harada, Linux Kernel Mailing List



Bruce Harada wrote:

>Suggestion: Chop your CCs. I sus pect Linus gave up on this topic a long time
>ago, as (most likely) have the majority of the others.
>
>On Wed, 16 Apr 2003 10:28:31 -0400
>Timothy Miller <miller@techsource.com> wrote:
>
>  
>
>>The Japanese are taught to read and write English as school children. 
>> They also are taught how to write their own language in Romanji, which 
>>is an adaptation of the Roman alphabet.
>>    
>>
>
>No, they're not (taught to write Japanese in Romaji, that is).
>  
>
Perhaps I was mistaken on that.

>  
>
>> How much you want to bet that 
>>the Japanese use English when they write error messages?
>>    
>>
>
>Well, it rather depends on the person... try setting your locale to
>ja_JP.eucJP, and you might be surprised by the applications that give you
>Japanese messages. Certainly, some Japanese people prefer messages in
>English, but that can hardly be generalized across the entire userbase.
>  
>
Applications.  Far more people work on applications than on the kernel.

I'm not saying I don't think Japanese would benefit from Japanese 
messages.  I'm saying that, in my humble estimation, i18n kernel 
messages would lose in the cost-benefit analysis.

>  
>
>>Linus Torvalds isn't the first Finn I've encountered who speaks, reads, 
>>and writes English impeccably.
>>
>>I've also never met a German who didn't speak English.
>>
>>When we have Asian vendors from various countries come visit where I 
>>work, even the ones who need a translator speak English better than we 
>>speak their language.
>>    
>>
>
>My only answer is, you have only had the opportunity to meet people from
>overseas who have some English ability... really, your argument is on the same
>level as "I've got lots of foreign friends who all like <whatever>, so all
>foreigners must like <whatever>."
>
You make a good point.

>
>Bruce
>
>
>PS: I'm against translating kernel messages, but for technical reasons (simple
>== good) rather than some wild idea that everybody else in the world can
>understand English.
>
I agree that an objective technical analysis, not personal opinion, 
should be the basis of our decision on this matter.




^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-16 14:28     ` Timothy Miller
  2003-04-16 14:37       ` Alan Cox
@ 2003-04-16 17:04       ` Bruce Harada
  2003-04-16 18:34         ` Timothy Miller
  1 sibling, 1 reply; 137+ messages in thread
From: Bruce Harada @ 2003-04-16 17:04 UTC (permalink / raw)
  To: Timothy Miller; +Cc: linux-kernel


Suggestion: Chop your CCs. I sus pect Linus gave up on this topic a long time
ago, as (most likely) have the majority of the others.

On Wed, 16 Apr 2003 10:28:31 -0400
Timothy Miller <miller@techsource.com> wrote:

> The Japanese are taught to read and write English as school children. 
>  They also are taught how to write their own language in Romanji, which 
> is an adaptation of the Roman alphabet.

No, they're not (taught to write Japanese in Romaji, that is).

>  How much you want to bet that 
> the Japanese use English when they write error messages?

Well, it rather depends on the person... try setting your locale to
ja_JP.eucJP, and you might be surprised by the applications that give you
Japanese messages. Certainly, some Japanese people prefer messages in
English, but that can hardly be generalized across the entire userbase.

> Linus Torvalds isn't the first Finn I've encountered who speaks, reads, 
> and writes English impeccably.
> 
> I've also never met a German who didn't speak English.
> 
> When we have Asian vendors from various countries come visit where I 
> work, even the ones who need a translator speak English better than we 
> speak their language.

My only answer is, you have only had the opportunity to meet people from
overseas who have some English ability... really, your argument is on the same
level as "I've got lots of foreign friends who all like <whatever>, so all
foreigners must like <whatever>."


Bruce


PS: I'm against translating kernel messages, but for technical reasons (simple
== good) rather than some wild idea that everybody else in the world can
understand English.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-16 14:37       ` Alan Cox
@ 2003-04-16 16:20         ` Timothy Miller
  0 siblings, 0 replies; 137+ messages in thread
From: Timothy Miller @ 2003-04-16 16:20 UTC (permalink / raw)
  To: Alan Cox
  Cc: Gerrit Huizenga, John Bradford, Chuck Ebbert, Linus Torvalds,
	Linux Kernel Mailing List



Alan Cox wrote:

>On Mer, 2003-04-16 at 15:28, Timothy Miller wrote:
>
>>The point of this painfully off-topic rant is that messages being 
>>written in English are a disadvantage for no one since they all already 
>>know English.  The messages are also simple enough that anyone
>>
>
>Thats a hopeless simplification for non techies and for some techies.
>

I recognize that having internationalized messages would be an 
advantage.  The question is whether or not that advantage outweighs the 
disadvantage.

This shouldn't stop anyone from working on it, however.  My message 
compression work only shaves off about 64k, MAYBE, which compared to the 
rest of the kernel footprint is tiny.  What you get is a more complex 
printk, no lower-case letters, and a meager space savings.  Embedded 
users might like it, but they'll start out with less text to compress in 
the first place; those who stand to benefit the most are the ones who 
can benefit the least.  Oh, and the build process will take at least 
twice as long.  IF this can be implemented in a way that makes it 
entirely transparent, maybe a few people will use it, so my primary 
motivation for doing it is that I'm enjoying working on it.  :)

>>I personally have a list of every kernel message I could extract from 
>>the source code of 2.4.20, and I've examined a lot of them.  It's a lot 
>>like reading Dr. Seuss.  Although some of the words are long, the 
>>vocabulary is incredibly small.  A lot of text is abbreviations and 
>>acronyms that you wouldn't translate anyhow!
>>
>
>I would be interested in how you extracted them, since a tool that can
>do this is the relevant 99% of the discussion, whether its for building
>message explanations, translation, reducing messages for embedded...
>
I used 2.4.20.  I modified Rules.make.  The line which does the compile 
(line 60), I changed like this:

%.o: %.c
    $(CPP) $(CFLAGS) $(EXTRA_CFLAGS_nostdinc) -DKBUILD_BASENAME=$(subst 
$(comma),_,$(subst -,_,$(*F))) $(CFLAGS_$@) $< > $<.i ; \
    $(CC) $(CFLAGS) $(EXTRA_CFLAGS_nostdinc) -DKBUILD_BASENAME=$(subst 
$(comma),_,$(subst -,_,$(*F))) $(CFLAGS_$@) -c -o $@ $<


When I built the kernel, for every .o file, I also got a .c.i file.  I 
used a script to scan the tree for .i files.  This is the script:

#!/bin/sh

for i in `ls -A | grep .i$`
do
    if [ -f $i ]
    then
        /home/tim/tmp/prkex < $i
    fi
done

for i in `ls -A`
do
    if [ -d $i ]
    then
    P=`pwd`
    cd $i
    $0
    cd $P
    fi
done



And here's 'prkex', a horrible little extraction program that I hacked 
together rather abruptly.  It doesn't do anything cool like use yacc or 
regex.  It gets the printk format strings using a half-wit state 
machine.  I figure I can get away with posting it because it's shorter 
than a lot of patches I see.  :)



#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>


/* This is implemented as a state-machine which parses the input for
   strings which match:
   printk("...", ...);
*/


/* This is to deal with backslash followed by octal.  Since I don't
   try to deal with that properly, it's kinda pointless to have this.
   oh well. */
int state_stack[10];
int top_state = 0;


#define STATE (state_stack[top_state])

char *printk_string = "printk";
char last_out = '\n';

/* When extracting words, \n is a separator.  We don't need redundant \n */
void output_char(char c)
{
    if (last_out == '\n' && c == '\n') return;
    last_out = c;
    putchar(c);
}


/* Find printk and look for everything in the format string.  Deal with
   concatenation of multiple partial strings and ignore anything outside
   of quotes (__FILE__, etc) until we hit , or ). */
void process_char(int c)
{
    switch (STATE) {
    case 5:   /* look for 'k' */
        if (c == printk_string[5]) {
            STATE = '(';
        } else {
            STATE = 0;
        }
        break;
    default:  /* Look for first 5 chars of 'printk' */
        if (STATE < 5) {
            if (c == printk_string[STATE]) {
                STATE++;
            } else {
                STATE = 0;
            }
        } else {
            STATE = 0;
        }
        break;
    case '(':  /* Look for ( */
        if (isspace(c)) return;
        if (c == '(') {
            STATE = '[';
        } else {
            STATE = 0;
        }
        break;
    case '[':  /* Look for " */
        if (isspace(c)) return;
        switch (c) {
        case 34:
            STATE = 34;
            break;
        case ')':
        case ',':
        case ';':
            output_char('\n');
            STATE = 0;
            break;
        default:
            /* default doesn't abort because we get __FILE__, etc. */
            output_char('\n');
            break;
        }
        break;
    case 34:    /* We're in a string */
        if (c == '\\') {
            top_state++;
            STATE = '\\';
            return;
        }
        if (c == 34) {
            STATE = '[';
            return;
        }
        output_char(c);
        break;
    case '\\':  /* partially deal with backslash. */
        if (state_stack[top_state-1] == 34) {
            switch (c) {
            case 'n':
                output_char('\n');
                break;
            case 't':
                output_char('\t');
                break;
            case '\n':
                break;
            default:
                output_char(c);
                break;
            }
        }
        top_state--;
        break;
    }
}       
       
           

int main(int argc, char *argv[])
{
    int c;
   
    state_stack[0] = 0;
   
    while (!feof(stdin)) {
        c = getchar();
        if (c != EOF) process_char(c);
    }
   
    return 0;
}



^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-16 14:28     ` Timothy Miller
@ 2003-04-16 14:37       ` Alan Cox
  2003-04-16 16:20         ` Timothy Miller
  2003-04-16 17:04       ` Bruce Harada
  1 sibling, 1 reply; 137+ messages in thread
From: Alan Cox @ 2003-04-16 14:37 UTC (permalink / raw)
  To: Timothy Miller
  Cc: Gerrit Huizenga, John Bradford, Chuck Ebbert, Linus Torvalds,
	Linux Kernel Mailing List

On Mer, 2003-04-16 at 15:28, Timothy Miller wrote:
> The point of this painfully off-topic rant is that messages being 
> written in English are a disadvantage for no one since they all already 
> know English.  The messages are also simple enough that anyone

Thats a hopeless simplification for non techies and for some techies.

> I personally have a list of every kernel message I could extract from 
> the source code of 2.4.20, and I've examined a lot of them.  It's a lot 
> like reading Dr. Seuss.  Although some of the words are long, the 
> vocabulary is incredibly small.  A lot of text is abbreviations and 
> acronyms that you wouldn't translate anyhow!

I would be interested in how you extracted them, since a tool that can
do this is the relevant 99% of the discussion, whether its for building
message explanations, translation, reducing messages for embedded...



^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-16  1:59   ` Gerrit Huizenga
@ 2003-04-16 14:28     ` Timothy Miller
  2003-04-16 14:37       ` Alan Cox
  2003-04-16 17:04       ` Bruce Harada
  0 siblings, 2 replies; 137+ messages in thread
From: Timothy Miller @ 2003-04-16 14:28 UTC (permalink / raw)
  To: Gerrit Huizenga; +Cc: John Bradford, Chuck Ebbert, Linus Torvalds, linux-kernel

The Japanese are taught to read and write English as school children. 
 They also are taught how to write their own language in Romanji, which 
is an adaptation of the Roman alphabet.  How much you want to bet that 
the Japanese use English when they write error messages?  While I 
understand the spirit of your statement, despite its technical error, 
the spirit of my response is that you could replace "Japanese" with any 
other language and get the same effect.

Linus Torvalds isn't the first Finn I've encountered who speaks, reads, 
and writes English impeccably.

I've also never met a German who didn't speak English.

When we have Asian vendors from various countries come visit where I 
work, even the ones who need a translator speak English better than we 
speak their language.

The point of this painfully off-topic rant is that messages being 
written in English are a disadvantage for no one since they all already 
know English.  The messages are also simple enough that anyone 
intelligent enough to care what a Linux kernel message MEANS is probably 
intelligent enough to at least have an English-to-Whatever dictionary on 
hand.

I personally have a list of every kernel message I could extract from 
the source code of 2.4.20, and I've examined a lot of them.  It's a lot 
like reading Dr. Seuss.  Although some of the words are long, the 
vocabulary is incredibly small.  A lot of text is abbreviations and 
acronyms that you wouldn't translate anyhow!

This isn't an issue of fairness to people who speak other languages. 
 It's simply unnecessary and costs us far more than we gain.  One of the 
things I like about the Linux kernel is that people strive to "do the 
right thing", and it's improving all the time.  Internationalizing 
kernel messages, that shouldn't appear anyhow if we did our jobs right, 
would NOT be an improvement.

Mind you, I like to try to be open-minded.  Based on my own reasoning, I 
see this as being unnecessary, but I can be convinced otherwise.  You're 
just going to have to come up with a much better reason than what has 
been offered by yourself and others in this thread.


Gerrit Huizenga wrote:

>On Fri, 11 Apr 2003 14:40:55 BST, John Bradford wrote:
>  
>
>>Well, you don't need error codes to make a comprehensive manual, you
>>can just look up the English error message, and get a detailed
>>explaination of it, in any language.
>>    
>>
>
>Can someone hand that man a japanese error message and ask him to
>look it up in a japanese dictionary?
>
>Walk for a moment in the other language's shoes...
>
>Mixing metaphores as time flies....
>
>gerrit
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>
>  
>



^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-14 14:23   ` Valdis.Kletnieks
@ 2003-04-16  5:03     ` Denis Vlasenko
  0 siblings, 0 replies; 137+ messages in thread
From: Denis Vlasenko @ 2003-04-16  5:03 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Chuck Ebbert, linux-kernel

On 14 April 2003 17:23, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 14 Apr 2003 14:40:46 +0300, Denis Vlasenko said:
> > OTOH "I can go read the source" is the ultimate documentation
> > which we have for zero extra effort.
>
> It's a non-zero extra effort for me to poke around in the source for
> drivers/video/riva/fbdev.c trying to find what parameters are legal
> to attach to 'video=rivafb' - at least one posting to LKML has listed
> append="video=rivafb,xres:1024,yres:768,bpp:8" but looking at the
> rivafb_setup() code that only checks for "forceCRTC", "flatpanel",
> and "nomtrr" - so even MORE digging is needed to find out who parses
> the xres, yres, bpp values, what other values are legal, etc etc.

I talked about entirely different matter: what happens when you read
some doc and either it does not answer your question or is
demonstrably wrong? In Linux, you say "Linux sucks" and go read the code.
In Windows/Oracle/etc you say "Windows sucks" and start banging your
head against the wall.
--
vda

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 13:40 ` John Bradford
@ 2003-04-16  1:59   ` Gerrit Huizenga
  2003-04-16 14:28     ` Timothy Miller
  0 siblings, 1 reply; 137+ messages in thread
From: Gerrit Huizenga @ 2003-04-16  1:59 UTC (permalink / raw)
  To: John Bradford; +Cc: Chuck Ebbert, Linus Torvalds, linux-kernel

On Fri, 11 Apr 2003 14:40:55 BST, John Bradford wrote:
> Well, you don't need error codes to make a comprehensive manual, you
> can just look up the English error message, and get a detailed
> explaination of it, in any language.

Can someone hand that man a japanese error message and ask him to
look it up in a japanese dictionary?

Walk for a moment in the other language's shoes...

Mixing metaphores as time flies....

gerrit

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-14 17:29     ` Linus Torvalds
                         ` (2 preceding siblings ...)
  2003-04-15 13:21       ` Alex Combas
@ 2003-04-15 18:02       ` Eric Altendorf
  2003-04-17 13:46         ` Alan Cox
  2003-04-17 15:07         ` Randolph Bentson
  3 siblings, 2 replies; 137+ messages in thread
From: Eric Altendorf @ 2003-04-15 18:02 UTC (permalink / raw)
  To: Linus Torvalds, John Bradford; +Cc: vda, Chuck Ebbert, linux-kernel

On Monday 14 April 2003 10:29, Linus Torvalds wrote:
> Personally, I don't write documentation. I don't much even write
> comments in my code. My personal feeling is that as long as
> functions are small and readable (and logical), and global
> variables have good names, that's all I need to do. Others - who do
> care about comments and docs - can do that part.

This is true, even from a software engineering perspective.

If you find yourself having to write comments and documentation to 
explain your code, probably your identifiers are not well named, your 
functions are not short enough, and your code is not well structured 
enough.

Ideal code is completely self-documenting.

Eric



^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-15  3:44         ` Robert White
  2003-04-15 11:08           ` Alan Cox
  2003-04-15 11:08           ` Alan Cox
@ 2003-04-15 14:07           ` Timothy Miller
  2 siblings, 0 replies; 137+ messages in thread
From: Timothy Miller @ 2003-04-15 14:07 UTC (permalink / raw)
  To: Robert White; +Cc: Riley Williams, Linux Kernel List



Robert White wrote:

>Message codes would be *VERY BAD* anyway.  As soon as you start that, then
>you need a numbering authority and all that nonsense.
>
>However, it should be "reasonably easy" to preprocess (in the gcc -E sense)
>all the files in a kernel directory and the gather up nearly all the
>prototype strings.  (you would still have the occasional person who wrote
>"char Message[] = "INode: %d invalid"; printk(Message,number);" instead of
>having the string in place as just "printk("INode: %d invalid",number);" and
>the later is easier to collect up 8-)
>
>The thing is "INode: %d invalid", as a string is easy to decompose into a
>regular expression because it is mostly-constant and the non-constant parts
>are represented with constant markers.  There are a small number of
>degenerate cases [e.g. printk("Filename %s invalid: %s","Filename","invalid:
>whitespace character")] that might need to be tweaked but nothing is
>perfect.
>
>So "the magic tool" collects these imprint strings and builds a list of all
>the strings (for the translator), a recognizer-table (perhaps hashes against
>the constant leader word of each message and a regex for the message) that
>points to the also-built hash/key into the table of all of the known
>strings.
>  
>

I'm working on this right now.  My plan is as follows:

- Use a C parser which takes .c or .i files and searches for the format 
parameter to every printk call.
- Provide that information to both a preprocessor and the printk function.
- Pipe every .c or .i file through an intermediate preprocessor before 
or after going to cpp but before the compiler.
- Do automatic string replacement.

Right now, I'm hovering somewhere around 40% compression on the text. 
 When I have better results, I will write up a full report and post it 
on lkml.

And, BTW, I will ONLY be supporting English.  As far as I am concerned, 
the internationalization is an concluded issue.  There's no benefit to 
it, and Linus won't accept it into mainline anyhow.



^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-14 17:29     ` Linus Torvalds
  2003-04-14 18:15       ` John Bradford
  2003-04-14 23:04       ` Felipe Alfaro Solana
@ 2003-04-15 13:21       ` Alex Combas
  2003-04-15 18:02       ` Eric Altendorf
  3 siblings, 0 replies; 137+ messages in thread
From: Alex Combas @ 2003-04-15 13:21 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

On Mon, 2003-04-14 at 10:29, Linus Torvalds wrote:

Hi Linus,
I hope Im not being a nerd..

> The whole open source idea is that people do what they care 
> about and what they are good at, and exactly because they aren't forced to 
> deal with issues they don't have a heart for they take  more pride and 
> interest in the stuff they _do_ do.

I thought the whole open source idea was that people could share quality
software that is free to view and modify. :)

> Personally, I don't write documentation. I don't much even write
> comments in my code.

Maybe Im too naive but I really believe that good commenting style
should be the default way for _all_ opensource developers to opperate
simply because the practise of "being free to view and modify code" is
helped by good comments. 

However I do understand that unpaid volunteers will tend to focus on the
things they enjoy more so than things they do not, and I dont have any
problems with that.

The Learning curve with a project this big is hellishly steep though, so
young ones such as myself can use all the code comments we can get.
I know it seems rather obnoxious to be telling you this, sorry.

Best Regards.

-- 
Alex Combas <ghetto_samurai@shaw.ca>
This message is digitally signed.
The public decryption key for my signature is available at pgp.mit.edu
Secure email is preferred.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-English user messages
  2003-04-15  3:44         ` Robert White
  2003-04-15 11:08           ` Alan Cox
@ 2003-04-15 11:08           ` Alan Cox
  2003-04-15 14:07           ` Timothy Miller
  2 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2003-04-15 11:08 UTC (permalink / raw)
  To: Robert White; +Cc: Riley Williams, Linux Kernel Mailing List

On Maw, 2003-04-15 at 04:44, Robert White wrote:
> Message codes would be *VERY BAD* anyway.  As soon as you start that, then
> you need a numbering authority and all that nonsense.

In the embedded world that isnt a problem. Ripping all the strings out
and replacing them with numbers is a useful process even if "Error
134117" is only constant in your product line.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-English user messages
  2003-04-15  3:44         ` Robert White
@ 2003-04-15 11:08           ` Alan Cox
  2003-04-15 11:08           ` Alan Cox
  2003-04-15 14:07           ` Timothy Miller
  2 siblings, 0 replies; 137+ messages in thread
From: Alan Cox @ 2003-04-15 11:08 UTC (permalink / raw)
  To: Robert White; +Cc: Riley Williams, Linux Kernel Mailing List

On Maw, 2003-04-15 at 04:44, Robert White wrote:
> Message codes would be *VERY BAD* anyway.  As soon as you start that, then
> you need a numbering authority and all that nonsense.

In the embedded world that isnt a problem. Ripping all the strings out
and replacing them with numbers is a useful process even if "Error
134117" is only constant in your product line.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-English user messages
  2003-04-11 22:53       ` Riley Williams
@ 2003-04-15  3:44         ` Robert White
  2003-04-15 11:08           ` Alan Cox
                             ` (2 more replies)
  0 siblings, 3 replies; 137+ messages in thread
From: Robert White @ 2003-04-15  3:44 UTC (permalink / raw)
  To: Riley Williams, Linux Kernel List

Message codes would be *VERY BAD* anyway.  As soon as you start that, then
you need a numbering authority and all that nonsense.

However, it should be "reasonably easy" to preprocess (in the gcc -E sense)
all the files in a kernel directory and the gather up nearly all the
prototype strings.  (you would still have the occasional person who wrote
"char Message[] = "INode: %d invalid"; printk(Message,number);" instead of
having the string in place as just "printk("INode: %d invalid",number);" and
the later is easier to collect up 8-)

The thing is "INode: %d invalid", as a string is easy to decompose into a
regular expression because it is mostly-constant and the non-constant parts
are represented with constant markers.  There are a small number of
degenerate cases [e.g. printk("Filename %s invalid: %s","Filename","invalid:
whitespace character")] that might need to be tweaked but nothing is
perfect.

So "the magic tool" collects these imprint strings and builds a list of all
the strings (for the translator), a recognizer-table (perhaps hashes against
the constant leader word of each message and a regex for the message) that
points to the also-built hash/key into the table of all of the known
strings.

The human translator comes along to prepare the table for the target
language, and populates a replacement-string table with the translations
with suitable $1, $2, etc. style markers for all the messages he can
translate.

At runtime, the translator takes the recognizer-table and does the hash on
the leader word, then tries the string against the regexes with the same
leader hash.  Every match (there should usually be only one) will net the
key hash which in turn leads to the human-supplied replacement line.  $1
style replacement takes place, and the line is emitted in the "new"
language.  IF there is no match, the unchanged line is produced.

It's cute in that in-elegant sort of way, but it *IS* deterministic and
extensible (if the unique hash/key algo can be worked out.)

In fact, such a system could be pointed at, say, the kernel archive, and
produce a translation of all the kernel messages (for a given kernel etc)
and leave the bulk of the message text untouched.

Rob.

-----Original Message-----
From: Riley Williams [mailto:Riley@Williams.Name]
Sent: Friday, April 11, 2003 3:53 PM
To: Robert White; Linux Kernel List
Subject: RE: kernel support for non-English user messages


Hi Robert.

 > Actually, my final point had been that doing it inside the kernel
 > itself, or indeed inside klogd, was probably a very bad idea. If
 > the translation always happens after-the-fact based on properly
 > harvested message semantics then any segment of messages
 > distributed into this mailing list (among other uses) would be
 >
 > A)  Still in English.
 > B)  Translatable after the fact there too.
 >
 > Also after-the-fact translation makes the language translations a
 > scalar problem instead of a matrix one. That is, if you always
 > pass the message stream around in English (treat it like n opaque
 > source file) and then translate it as necessary, it will "always
 > work".
 >
 > If you try to do the translations at message generation time, then
 > the translation must be any-language-to-any-language capable during
 > post-even discussions. Not good.

I can see the points you're making, and that is precisely why I believe
that message codes would be required to implement this idea. As Linus
has vetoed the idea of having message codes in the kernel, I can't see
it ever coming to fruition.

 > Also, you will always have leakage as people add new strings to the
 > set.

That's the easiest aspect of dealing with it - the tool that generates
the language set to use just grabs the "English" language version for
any message codes not in the selected translation.

 > As for the #define issues, when you process the source tree to build the
 > source matrix you just "gcc -E file.c | collector" and now the printk
 > case you mention is handled. Any module designer who does uglier things
 > can make a dead-code procedure that expresses his possible output strings
 > for collection (if he cares.)

 > {Satire}

 > Speaking as an arrogant (U.S. of) American who knows that God(TradeMark,
 > all rights reserved) decreed that he never had to learn any language but
 > his own, I can honestly state, that it is nearly certain that you will
 > get no real support for the multi-language kernel out of a us
USAmericans.
 > We can't even get ourselves to write decent comments, and on the average,
 > we all secretly believe that if we just speak slowly enough everybody
 > really knows English. After all, that's how our condescending "wouldn't
 > want to fail Johnny, it would be bad for his self-image" public schools
 > taught us in the first place.... 8-)

Speaking as an amused (U.S. of) American, I long ago learned how to tell
when
somebody is speaking "God's Language"(tm) - that's simple to work out. After
all, the most likely people to speak "God's Language"(tm) are those that
have
just left His presence - the new born babies - so if we want to listen to
His
language, we just listen to them speak it. What could be simpler???

However, I understand "God's Language"(tm) is not currently understood well
enough by the kernel developers for any of them to translate the kernel
messages into it...

 > {/Satire}

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.471 / Virus Database: 269 - Release Date: 10-Apr-2003


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-14 17:29     ` Linus Torvalds
  2003-04-14 18:15       ` John Bradford
@ 2003-04-14 23:04       ` Felipe Alfaro Solana
  2003-04-15 13:21       ` Alex Combas
  2003-04-15 18:02       ` Eric Altendorf
  3 siblings, 0 replies; 137+ messages in thread
From: Felipe Alfaro Solana @ 2003-04-14 23:04 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: John Bradford, vda, Chuck Ebbert, linux-kernel

On Mon, 2003-04-14 at 19:29, Linus Torvalds wrote:
> Some people care about documentation, some people don't. That's a fact,
> and spouting platitudes about "improving their work" just doesn't
> _matter_. The whole open source idea is that people do what they care 
> about and what they are good at, and exactly because they aren't forced to 
> deal with issues they don't have a heart for they take  more pride and 
> interest in the stuff they _do_ do.

Newbies as me do care about documentation ;-) The Linux kernel is
getting more complex over time, and I appreciate some kind of
architectural docs to know more about the inner workings. Personally, I
don't have all the time I would like to explore and investigate, so a
50,000-feet-point-of-view and some detailed documentation about VM,
scheduler and net are welcome.

Kernel experts as you (Linus, Andrew, Alan, Russell, Jeff and many
others whose names I must leave out as I don't have space to name them
all) probably know the inner workings better than anyone as they work
with it every day, but people new to kernel hacking need some starting
point.

> Personally, I don't write documentation. I don't much even write comments
> in my code. My personal feeling is that as long as functions are small and
> readable (and logical), and global variables have good names, that's all I
> need to do. Others - who do care about comments and docs - can do that
> part.

Well, some functions and variable names may seem readable and logical to
some, but it takes time for me to decipher some of them :-)

-- 
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Linux Registered User #287198


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
@ 2003-04-14 21:27 Chuck Ebbert
  0 siblings, 0 replies; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-14 21:27 UTC (permalink / raw)
  To: vda; +Cc: linux-kernel

vda wrote:


> OTOH "I can go read the source" is the ultimate documentation
> which we have for zero extra effort.


  ...except for that required to actually understand it.

--
 CHuck

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-14 17:29     ` Linus Torvalds
@ 2003-04-14 18:15       ` John Bradford
  2003-04-14 23:04       ` Felipe Alfaro Solana
                         ` (2 subsequent siblings)
  3 siblings, 0 replies; 137+ messages in thread
From: John Bradford @ 2003-04-14 18:15 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: John Bradford, vda, Chuck Ebbert, linux-kernel

> > Anybody who doesn't document their code is wasting an opportunity to
> > improve their work.
> 
> Some people care about documentation, some people don't. That's a fact,
> and spouting platitudes about "improving their work" just doesn't
> _matter_.

[snip]

> And you know what? That _lack_ of comments and documantation improves my 
> work. Not because documentation is bad, but because I DO NOT CARE. So I 
> concentrate on the stuff I do care about.
> 
> So no, people are _NOT_ "wasting an opportunity". 

You are right on this one, I appologise.  

Substitute 'indenting' for 'comments and documentation' and I could
have written that last paragraph myself.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-14 12:55   ` John Bradford
@ 2003-04-14 17:29     ` Linus Torvalds
  2003-04-14 18:15       ` John Bradford
                         ` (3 more replies)
  0 siblings, 4 replies; 137+ messages in thread
From: Linus Torvalds @ 2003-04-14 17:29 UTC (permalink / raw)
  To: John Bradford; +Cc: vda, Chuck Ebbert, linux-kernel


On Mon, 14 Apr 2003, John Bradford wrote:
> 
> Anybody who doesn't document their code is wasting an opportunity to
> improve their work.

Some people care about documentation, some people don't. That's a fact,
and spouting platitudes about "improving their work" just doesn't
_matter_. The whole open source idea is that people do what they care 
about and what they are good at, and exactly because they aren't forced to 
deal with issues they don't have a heart for they take  more pride and 
interest in the stuff they _do_ do.

Personally, I don't write documentation. I don't much even write comments
in my code. My personal feeling is that as long as functions are small and
readable (and logical), and global variables have good names, that's all I
need to do. Others - who do care about comments and docs - can do that
part.

And you know what? That _lack_ of comments and documantation improves my 
work. Not because documentation is bad, but because I DO NOT CARE. So I 
concentrate on the stuff I do care about.

So no, people are _NOT_ "wasting an opportunity". 

			Linus


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-14 11:40 ` Denis Vlasenko
  2003-04-14 12:55   ` John Bradford
  2003-04-14 13:18   ` Sean Neakums
@ 2003-04-14 14:23   ` Valdis.Kletnieks
  2003-04-16  5:03     ` Denis Vlasenko
  2 siblings, 1 reply; 137+ messages in thread
From: Valdis.Kletnieks @ 2003-04-14 14:23 UTC (permalink / raw)
  To: vda; +Cc: Chuck Ebbert, Linus Torvalds, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

On Mon, 14 Apr 2003 14:40:46 +0300, Denis Vlasenko said:

> OTOH "I can go read the source" is the ultimate documentation
> which we have for zero extra effort.

It's a non-zero extra effort for me to poke around in the source for
drivers/video/riva/fbdev.c trying to find what parameters are legal
to attach to 'video=rivafb' - at least one posting to LKML has listed
append="video=rivafb,xres:1024,yres:768,bpp:8" but looking at the
rivafb_setup() code that only checks for "forceCRTC", "flatpanel", and
"nomtrr" - so even MORE digging is needed to find out who parses the
xres, yres, bpp values, what other values are legal, etc etc.





[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-14 11:40 ` Denis Vlasenko
  2003-04-14 12:55   ` John Bradford
@ 2003-04-14 13:18   ` Sean Neakums
  2003-04-14 14:23   ` Valdis.Kletnieks
  2 siblings, 0 replies; 137+ messages in thread
From: Sean Neakums @ 2003-04-14 13:18 UTC (permalink / raw)
  To: linux-kernel

Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> writes:

> OTOH "I can go read the source" is the ultimate documentation
> which we have for zero extra effort.

The problem with this approach is that when the code has a bug, the
documentation has a bug.

-- 
Sean Neakums - <sneakums@zork.net>

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-14 11:40 ` Denis Vlasenko
@ 2003-04-14 12:55   ` John Bradford
  2003-04-14 17:29     ` Linus Torvalds
  2003-04-14 13:18   ` Sean Neakums
  2003-04-14 14:23   ` Valdis.Kletnieks
  2 siblings, 1 reply; 137+ messages in thread
From: John Bradford @ 2003-04-14 12:55 UTC (permalink / raw)
  To: vda; +Cc: Chuck Ebbert, Linus Torvalds, linux-kernel

> OTOH "I can go read the source" is the ultimate documentation
> which we have for zero extra effort.

Anybody who doesn't document their code is wasting an opportunity to
improve their work.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 22:21 kernel support for non-English " Chuck Ebbert
  2003-04-11 22:53 ` Martin J. Bligh
  2003-04-12  7:48 ` John Bradford
@ 2003-04-14 11:40 ` Denis Vlasenko
  2003-04-14 12:55   ` John Bradford
                     ` (2 more replies)
  2 siblings, 3 replies; 137+ messages in thread
From: Denis Vlasenko @ 2003-04-14 11:40 UTC (permalink / raw)
  To: Chuck Ebbert, Linus Torvalds; +Cc: linux-kernel

On 12 April 2003 01:21, Chuck Ebbert wrote:
>  Today it's all HTML documents or PDFs or something, but it's still
> a staggering amount of information.  I have ~300MB of Oracle
> documentation on one desktop, 6 of it server error messages alone.
> Every possible message is explained to some extent, except this one:
-snip-
> which is currently pretty much the only explanation available for
> a whole lot of Linux error messages. I can go read the source when
> e.g. the md driver splats its internal status dumps all over the
> console during array rebuild, but that doesn't help much.

I imagine keeping Oracle docs in shape is itself a huge task.
And frankly, it does not always help.

OTOH "I can go read the source" is the ultimate documentation
which we have for zero extra effort.
--
vda

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-12 20:31 Chuck Ebbert
@ 2003-04-14  9:07 ` Denis Vlasenko
  0 siblings, 0 replies; 137+ messages in thread
From: Denis Vlasenko @ 2003-04-14  9:07 UTC (permalink / raw)
  To: Chuck Ebbert, Alan Cox; +Cc: linux-kernel

On 12 April 2003 23:31, Chuck Ebbert wrote:
> >>   /Documentation is *awful*.
> >
> > You know where to submit contributions
>
>   If I could *write* the documentation, I wouldn't need it,
> now would I?  Maybe that's the problem...

If nobody would write the docs, nobody would read them ;)
--
vda

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-12 15:34 ` Alan Cox
  2003-04-12 17:22   ` Robert P. J. Day
@ 2003-04-13  6:21   ` John Bradford
  1 sibling, 0 replies; 137+ messages in thread
From: John Bradford @ 2003-04-13  6:21 UTC (permalink / raw)
  To: Alan Cox; +Cc: Chuck Ebbert, John Bradford, Linux Kernel Mailing List

> On Sad, 2003-04-12 at 16:20, Chuck Ebbert wrote:
> > > /Documentation could be a lot better than it is...  Some of it
> > > is very out of date.
> > 
> > 
> >   You are being way too kind.
> > 
> >   /Documentation is *awful*.
> 
> You know where to submit contributions

Aim the flame thrower further away from me :-)

I suggested a grepme file, and nobody seemed interested.  The
documentation needs to be improved, but how?  Suggestions would be
useful here...

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-12 17:22   ` Robert P. J. Day
@ 2003-04-13  3:59     ` Martin J. Bligh
  0 siblings, 0 replies; 137+ messages in thread
From: Martin J. Bligh @ 2003-04-13  3:59 UTC (permalink / raw)
  To: Robert P. J. Day, Alan Cox
  Cc: Chuck Ebbert, John Bradford, Linux Kernel Mailing List

>> > > /Documentation could be a lot better than it is...  Some of it
>> > > is very out of date.
>> > 
>> > 
>> >   You are being way too kind.
>> > 
>> >   /Documentation is *awful*.
>> 
>> You know where to submit contributions
> 
> this is, from a personal perspective, simply too timely to pass up. in
> fact, i have submitted six different patches, all aimed at either
> improving the documentation or cleaning up configuration menus.
> 
> without exception, every patch i have submitted directly has been dropped
> without comment.  the only one that was eventually accepted (rearranged
> filesystems menu) was because someone else with more authority and higher
> up the kernel-hacker food chain was gracious enough to submit it on my
> behalf.

Well, that's often what it takes, I'm afraid ... going direct to Linus is
by no means the only way to work, and it's often not the easiest. Try 
picking someone who's interested in the area you're working on, if possible
(ideally the maintainer if you can work out who it is). Failing that, try 
Andrew or Alan or both. 

> yes, i've read the "SubmittingPatches" guide, and at the risk of offending
> a few people, i find it pretty irritating, if not downright patronizing,
> to suggest that one should *expect* to have patches dropped without
> comment, and should *expect* to have to work hard at resubmitting the same
> patch until it takes.

It's a bit like Darwinian evolution, or Democracy ... both rather horribly
inefficient, but overall it's reasonably effective. Yeah, it's crap
sometimes. Sorry.

M.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
@ 2003-04-12 20:31 Chuck Ebbert
  2003-04-14  9:07 ` Denis Vlasenko
  0 siblings, 1 reply; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-12 20:31 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel


>>   /Documentation is *awful*.
>
> You know where to submit contributions


  If I could *write* the documentation, I wouldn't need it,
now would I?  Maybe that's the problem...


--
 Chuck
 Why is my email address an octal number?

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-12 15:34 ` Alan Cox
@ 2003-04-12 17:22   ` Robert P. J. Day
  2003-04-13  3:59     ` Martin J. Bligh
  2003-04-13  6:21   ` John Bradford
  1 sibling, 1 reply; 137+ messages in thread
From: Robert P. J. Day @ 2003-04-12 17:22 UTC (permalink / raw)
  To: Alan Cox; +Cc: Chuck Ebbert, John Bradford, Linux Kernel Mailing List

On 12 Apr 2003, Alan Cox wrote:

> On Sad, 2003-04-12 at 16:20, Chuck Ebbert wrote:
> > > /Documentation could be a lot better than it is...  Some of it
> > > is very out of date.
> > 
> > 
> >   You are being way too kind.
> > 
> >   /Documentation is *awful*.
> 
> You know where to submit contributions

this is, from a personal perspective, simply too timely to pass up. in
fact, i have submitted six different patches, all aimed at either
improving the documentation or cleaning up configuration menus.

without exception, every patch i have submitted directly has been dropped
without comment.  the only one that was eventually accepted (rearranged
filesystems menu) was because someone else with more authority and higher
up the kernel-hacker food chain was gracious enough to submit it on my
behalf.

yes, i've read the "SubmittingPatches" guide, and at the risk of offending
a few people, i find it pretty irritating, if not downright patronizing,
to suggest that one should *expect* to have patches dropped without
comment, and should *expect* to have to work hard at resubmitting the same
patch until it takes.

it's pretty counter-productive to suggest that there are a *number* of
reasons why a patch might be discarded -- does not apply cleanly, 
style issue, perhaps too trivial, what have you -- but not give any
indication as to what that reason might be.  am i supposed to go back
and take a closer look?  take a wild guess?  resubmit unchanged?

as someone who hasn't been here that long and is still feeling my 
way around, i can appreciate how much work it is to be responsible
for the numerous patches that are submitted.

but it seems more than a little hypocritical to invite patches to fix
things like documentation if those patches will just be tossed
unanswered.

if you'd like patches to improve things like menu layout or documentation,
let me know, i'll be glad to help.  if not, let me know that, too,  so i
can move on to other things and stop wasting my time.

rday



^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-English user messages
@ 2003-04-12 16:47 Chuck Ebbert
  0 siblings, 0 replies; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-12 16:47 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel


> You are right about needing to log parameters, but given a log line
> of the form
>
> %s: went up in flames\n\0eth0\0\0
>
> that can be handled by the log viewer


  How about this scheme instead?

    printk("%s: went up in flames\n", "eth0");

would become

    \0eth0\0: went up in flames\n\0\0

i.e. the zeros would mark a transition between text that came from
parameters and what was from the format string.  This would be a
lot easier to write to the console.


--
 "Let's fight till six, and then have dinner," said Tweedledum.
  --Lewis Carroll, _Through the Looking Glass_

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-12 15:20 Chuck Ebbert
@ 2003-04-12 15:34 ` Alan Cox
  2003-04-12 17:22   ` Robert P. J. Day
  2003-04-13  6:21   ` John Bradford
  0 siblings, 2 replies; 137+ messages in thread
From: Alan Cox @ 2003-04-12 15:34 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: John Bradford, Linux Kernel Mailing List

On Sad, 2003-04-12 at 16:20, Chuck Ebbert wrote:
> > /Documentation could be a lot better than it is...  Some of it
> > is very out of date.
> 
> 
>   You are being way too kind.
> 
>   /Documentation is *awful*.

You know where to submit contributions


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
@ 2003-04-12 15:20 Chuck Ebbert
  2003-04-12 15:34 ` Alan Cox
  0 siblings, 1 reply; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-12 15:20 UTC (permalink / raw)
  To: John Bradford; +Cc: linux-kernel


> /Documentation could be a lot better than it is...  Some of it
> is very out of date.


  You are being way too kind.

  /Documentation is *awful*.

--
 "Let's fight till six, and then have dinner," said Tweedledum.
  --Lewis Carroll, _Through the Looking Glass_

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-12  8:22 ` Kai Henningsen
@ 2003-04-12 11:08   ` John Bradford
  0 siblings, 0 replies; 137+ messages in thread
From: John Bradford @ 2003-04-12 11:08 UTC (permalink / raw)
  To: Kai Henningsen; +Cc: linux-kernel

> > > I've used VMS, and error code number encoding is a total heap of crap.
> >
> >
> >  Maybe for developers, but users like it.  I can still remember back in
> > the Old Days, taking those error codes and looking them up in something
> > called a "manual" where there was a coherent explanation of
> > what had gone wrong and even suggestions on what to do about it.
> 
> I think that's the real point here: without a manual to look things up in,  
> none of this actually buys us anything.

Agreed.

> The grepme file someone proposed

It was me.  I'm happy to maintain it, if there is sufficient interest.

> seems to be a reasonable first step,  
> starting to number or otherways add a code to everything doesn't - it may  
> or may not be a reasonable thing after there is experience with the grepme  
> file, but we don't have that experience right now so we don't know.

Agreed.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-English user messages
@ 2003-04-12  9:52 Chuck Ebbert
  0 siblings, 0 replies; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-12  9:52 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel

Alan Cox wrote:


> %s: went up in flames\n\0eth0\0\0


  You could make the placeholder just '%' instead of '%s' if you
were only writing zero-terminated strings.

  Every little bit helps.

--
 "Let's fight till six, and then have dinner," said Tweedledum.
  --Lewis Carroll, _Through the Looking Glass_

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 13:17 kernel support for non-English " Chuck Ebbert
                   ` (2 preceding siblings ...)
  2003-04-11 16:00 ` Linus Torvalds
@ 2003-04-12  8:22 ` Kai Henningsen
  2003-04-12 11:08   ` John Bradford
  3 siblings, 1 reply; 137+ messages in thread
From: Kai Henningsen @ 2003-04-12  8:22 UTC (permalink / raw)
  To: linux-kernel

76306.1226@compuserve.com (Chuck Ebbert)  wrote on 11.04.03 in <200304110919_MC3-1-33FD-6E7@compuserve.com>:

> Linux Torvalds wrote:
>
>
> > I've used VMS, and error code number encoding is a total heap of crap.
>
>
>  Maybe for developers, but users like it.  I can still remember back in
> the Old Days, taking those error codes and looking them up in something
> called a "manual" where there was a coherent explanation of
> what had gone wrong and even suggestions on what to do about it.

I think that's the real point here: without a manual to look things up in,  
none of this actually buys us anything.

The grepme file someone proposed seems to be a reasonable first step,  
starting to number or otherways add a code to everything doesn't - it may  
or may not be a reasonable thing after there is experience with the grepme  
file, but we don't have that experience right now so we don't know.

Oh, yes: one thing *might* make sense: have a script to extract kernel  
messages, and have source conventions to support that script, such as:
* when a message is built with more than one statement, some way to figure  
out where it starts and ends.
* a way to attach a comment that can be extracted by that script as an  
explanation of the message.




(Which makes me think it might be a nice gcc extension (in general, not  
necessarily for the above thing - actually, probably not for that, so take  
this as an unrelated aside) to have function-relative line numbers  
available as some sort of symbol. __FUNCTION__ (or __PRETTY_FUNCTION__)  
together with that (and possibly __FILE__) would make a semi-stable  
identifier - it only changes when that function is changed, as opposd to  
when anything is changed that happens to be before that function in the  
same source. Of course, many variations of that idea are imaginable.)

MfG Kai

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 22:53 ` Martin J. Bligh
@ 2003-04-12  7:55   ` John Bradford
  0 siblings, 0 replies; 137+ messages in thread
From: John Bradford @ 2003-04-12  7:55 UTC (permalink / raw)
  To: Martin J. Bligh; +Cc: Chuck Ebbert, linux-kernel

> >  Today it's all HTML documents or PDFs or something, but it's still
> > a staggering amount of information.  I have ~300MB of Oracle
> > documentation on one desktop, 6 of it server error messages alone.
> > Every possible message is explained to some extent, except this one:
> 
> IMHO, it'd be better to just make the kernel error messages meaningful.
> Keeping a large pile of documentation in sync with the source is
> a PITA.

You don't have to keep it in sync with the source - just make sure
that any documentation always mentions which versions it relates to.

If the documentation gets outdated, and everybody is aware of that, we
are no worse off than we are now.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 22:21 kernel support for non-English " Chuck Ebbert
  2003-04-11 22:53 ` Martin J. Bligh
@ 2003-04-12  7:48 ` John Bradford
  2003-04-14 11:40 ` Denis Vlasenko
  2 siblings, 0 replies; 137+ messages in thread
From: John Bradford @ 2003-04-12  7:48 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: Linus Torvalds, linux-kernel

> > I thought you might be seriously in need of some mental evaluation
> > when you claimed that users "liked looking up error numbers in
> > manuals".
> 
>  Not the looking up part, but that fact that the explanation
> for every single message the software could emit was available.
> 
>  Today it's all HTML documents or PDFs or something, but it's still
> a staggering amount of information.  I have ~300MB of Oracle
> documentation on one desktop, 6 of it server error messages alone.
> Every possible message is explained to some extent, except this one:

[SNIP]

> which is currently pretty much the only explanation available for
> a whole lot of Linux error messages. I can go read the source when e.g.
> the md driver splats its internal status dumps all over the console
> during array rebuild, but that doesn't help much.

/Documentation could be a lot better than it is...  Some of it is very
out of date.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
@ 2003-04-11 23:38 Chuck Ebbert
  0 siblings, 0 replies; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-11 23:38 UTC (permalink / raw)
  To: Matti Aarnio; +Cc: linux-kernel


>> > %s: went up in flames\n\0eth0\0\0
>> 
>>   Is that "\n" an actual ASCII newline or the printk escape sequence?
>
>The backslash is not "printk escape".  It is C-string compilation 
>notation.


  Oops, I guess I was mixing up which layer does what.


--
 "Let's fight till six, and then have dinner," said Tweedledum.
  --Lewis Carroll, _Through the Looking Glass_

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
@ 2003-04-11 23:36 Jim Keniston[UNIX]
  0 siblings, 0 replies; 137+ messages in thread
From: Jim Keniston[UNIX] @ 2003-04-11 23:36 UTC (permalink / raw)
  To: LKML

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

On Fri, 2003-04-11 at 12:16, Alan Cox wrote:

> Providing the viewer is translating the originals always exist. Indeed
> you can do
> 
>         LANG=es view-logs
>         LANG=ru view-logs
>         ...
> 
> You can have sysadmins with no common language("not a recommended
> configuration" ;))
> 
> You are right about needing to log parameters, but given a log line
> of the form
> 
> %s: went up in flames\n\0eth0\0\0
> 
> that can be handled by the log viewer

Other contributors have also endorsed the idea of creating a message
log where the format and args are kept separate.  Here's code to do it.

Enclosed is a patch that adds support for logging kernel events to a
structured event log (see evlog.sourceforge.net).  When EVLOG_FWPRINTK
is enabled, printk messages are automatically forwarded to the event
log in this form.  (They are also logged to klogd/syslogd, as usual.)

The log viewer (evlview) can reconstruct the complete message from the
components.  If you provide translations (AKA formatting templates) for
particular messages, and set your LANG environment variable
appropriately,
evlview will display those messages in the selected language.  (Messages
without translations are displayed in English.)

A few more notes about this event-logging support:
- printk calls don't change; one line is added to printk(), about 20 to
printk.c.
- Like syslog, it also handles messages from user space.  There are also
a variety of other ways to use this support to log information from the
kernel.
- User-mode event logging requires no kernel support.
- There's a bunch of stuff that sysadmins and tech support people have
found useful, such as APIs for examining the log and receiving
notification
of events.

See evlog.sourceforge.net for more info.

Jim Keniston
IBM Linux Technology Center

[-- Attachment #2: evlog-1.5.2_kernel-2.5.67.patch --]
[-- Type: text/plain, Size: 35393 bytes --]

diff -Naur linux.org/include/linux/evl_log.h linux.kernel.patched/include/linux/evl_log.h
--- linux.org/include/linux/evl_log.h	Wed Dec 31 16:00:00 1969
+++ linux.kernel.patched/include/linux/evl_log.h	Fri Apr 11 15:27:45 2003
@@ -0,0 +1,142 @@
+/*
+ * Linux Event Logging for the Enterprise
+ * Copyright (c) International Business Machines Corp., 2003
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ *  Please send e-mail to lkessler@users.sourceforge.net if you have
+ *  questions or comments.
+ *
+ *  Project Website:  http://evlog.sourceforge.net/
+ *
+ */
+
+#ifndef _LINUX_EVL_LOG_H
+#define _LINUX_EVL_LOG_H
+
+#ifndef __KERNEL__
+#ifdef _POSIX_THREADS
+#include <pthread.h>
+#endif
+#endif
+
+/* Values for log_flags member */
+#define POSIX_LOG_TRUNCATE  0x1
+#define EVL_KERNEL_EVENT	0x2
+#define EVL_INITIAL_BOOT_EVENT 	0x4
+#define EVL_KERNTIME_LOCAL	0x8
+#define EVL_INTERRUPT		0x10	/* Logged from interrupt context */
+#define EVL_PRINTK		0x20	/* Logged by printk() */
+
+/* Formats for optional portion of record. */
+#define POSIX_LOG_NODATA    0
+#define POSIX_LOG_BINARY    1
+#define POSIX_LOG_STRING    2
+#define POSIX_LOG_PRINTF    3
+
+/* Maximum length of variable portion of record */
+#define POSIX_LOG_ENTRY_MAXLEN      (8 * 1024)
+
+/* Maximum length for a string returned by posix_log_memtostr */
+/* Thus also the max length of a facility name */
+#define POSIX_LOG_MEMSTR_MAXLEN	128
+
+typedef unsigned int posix_log_facility_t;
+typedef int posix_log_severity_t;
+typedef int posix_log_recid_t;
+typedef int posix_log_procid_t;
+
+#define EVL_INVALID_FACILITY ((posix_log_facility_t)-1)
+
+struct posix_log_entry {
+	unsigned int            log_magic;
+        posix_log_recid_t   	log_recid;
+        size_t          	log_size;
+        int             	log_format;
+        int             	log_event_type;
+        posix_log_facility_t 	log_facility;
+        posix_log_severity_t    log_severity;
+        uid_t           	log_uid;
+        gid_t           	log_gid;
+        pid_t           	log_pid;
+        pid_t           	log_pgrp;
+        struct timespec 	log_time;
+        unsigned int    	log_flags;
+#ifdef __KERNEL__
+        unsigned long int	log_thread;
+#else
+#ifdef _POSIX_THREADS
+	pthread_t		log_thread;
+#else
+	unsigned long int	log_thread;
+#endif
+#endif
+        posix_log_procid_t	log_processor;
+}; 
+
+typedef struct posix_log_entry rec_hdr_t;
+typedef struct evl_buf_rec {
+        struct posix_log_entry  rechdr;
+        char                    varbuf[1];
+} evl_buf_rec_t;
+
+
+#define LOGFILE_MAGIC   0xbeefface
+#define LOGREC_MAGIC    0xfeefface
+#define REC_HDR_SIZE    sizeof(struct posix_log_entry)
+
+/*
+ * Reserved Event Types
+ */
+#define EVL_SYSLOG_MESSAGE      0x1
+#define EVL_PRINTK_MESSAGE      0x2
+#define EVL_BUFFER_OVERRUN      0x6
+#define EVL_DUPS_DISCARDED      0x7
+
+#define LOG_LOGMGMT              (12<<3)	/* EVL Facility */
+
+#ifdef __KERNEL__
+/*
+ * Reserved Facilities
+ */
+#define LOG_KERN        (0<<3)  /* Kernel Facility */
+#define LOG_AUTHPRIV    (10<<3) /* security/authorization messages (private) */
+/*
+ * priorities (these are ordered)
+ */
+#define LOG_EMERG   0   /* system is unusable */
+#define LOG_ALERT   1   /* action must be taken immediately */
+#define LOG_CRIT    2   /* critical conditions */
+#define LOG_ERR     3   /* error conditions */
+#define LOG_WARNING 4   /* warning conditions */
+#define LOG_NOTICE  5   /* normal but significant condition */
+#define LOG_INFO    6   /* informational */
+#define LOG_DEBUG   7   /* debug-level messages */
+
+#ifdef CONFIG_EVLOG
+extern int posix_log_write(posix_log_facility_t facility, int event_type,
+         	posix_log_severity_t severity, const void *buf,
+        	size_t len, int format, unsigned int flags);
+#else	/* ! CONFIG_EVLOG */
+inline int posix_log_write(posix_log_facility_t facility, int event_type,
+		posix_log_severity_t severity, const void *buf,
+		size_t len, int format, unsigned int flags)
+		{ return -ENOSYS; }
+#endif	/* CONFIG_EVLOG */
+
+#endif	/* __KERNEL__ */
+
+#endif	/* _LINUX_EVL_LOG_H */
diff -Naur linux.org/init/Kconfig linux.kernel.patched/init/Kconfig
--- linux.org/init/Kconfig	Fri Apr 11 15:27:45 2003
+++ linux.kernel.patched/init/Kconfig	Fri Apr 11 15:27:45 2003
@@ -92,6 +92,35 @@
 	  building a kernel for install/rescue disks or your system is very
 	  limited in memory.
 
+config EVLOG
+	bool "Enterprise event logging support"
+	help
+	  This enables support for enterprise-level event logging based
+	  upon the draft POSIX 1003.25 standard.  Enabling this feature
+	  does not affect the operation of the sysklogd package in any
+	  way.  In order to fully utilize this feature, user must also
+	  install the companion evlog package in user-space.
+
+	  For more information see http://evlog.sourceforge.net
+
+	  If you don't know what to do here, say N.
+
+config EVLOG_BUFSIZE
+	int "Event log buffer size (in Kbytes)"
+	depends on EVLOG
+	default "128"
+	help
+	  Event log buffer size in Kbytes. Default size is 128 Kbytes.
+
+config EVLOG_FWPRINTK
+	bool "Forward printk messages to enterprise event log"
+	depends on EVLOG
+	help
+	  This option forwards printk log messages to the enterprise event
+	  log.  Printk messages are still logged to /var/log/messages.
+
+	  If you don't know what to do here, say N.
+
 config LOG_BUF_SHIFT
 	int "Kernel log buffer size" if DEBUG_KERNEL
 	default 17 if ARCH_S390
diff -Naur linux.org/kernel/Makefile linux.kernel.patched/kernel/Makefile
--- linux.org/kernel/Makefile	Fri Apr 11 15:27:45 2003
+++ linux.kernel.patched/kernel/Makefile	Fri Apr 11 15:27:45 2003
@@ -18,6 +18,7 @@
 obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
 obj-$(CONFIG_SOFTWARE_SUSPEND) += suspend.o
 obj-$(CONFIG_COMPAT) += compat.o
+obj-$(CONFIG_EVLOG) += evlog.o
 
 ifneq ($(CONFIG_IA64),y)
 # According to Alan Modra <alan@linuxcare.com.au>, the -fno-omit-frame-pointer is
diff -Naur linux.org/kernel/evlog.c linux.kernel.patched/kernel/evlog.c
--- linux.org/kernel/evlog.c	Wed Dec 31 16:00:00 1969
+++ linux.kernel.patched/kernel/evlog.c	Fri Apr 11 15:27:45 2003
@@ -0,0 +1,933 @@
+/*
+ * Linux Event Logging for the Enterprise
+ * Copyright (c) International Business Machines Corp., 2003
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ *  Please send e-mail to lkessler@users.sourceforge.net if you have
+ *  questions or comments.
+ *
+ *  Project Website:  http://evlog.sourceforge.net/
+ *
+ */
+
+
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/fs.h>
+#include <linux/spinlock.h>
+#include <linux/time.h>
+#include <linux/smp.h>
+#include <linux/sched.h>
+#include <linux/ptrace.h>
+#include <linux/string.h>
+#include <linux/interrupt.h>
+#include <asm/uaccess.h>
+#include <asm/semaphore.h>
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/nls.h>
+#include <linux/ctype.h>
+#include <linux/console.h>
+#include <linux/smp_lock.h>
+#include <linux/crc32.h>
+
+#ifdef __i386__
+#include <asm/fixmap.h>
+#include <asm/mpspec.h>
+#include <asm/io_apic.h>
+#include <asm/apic.h>
+#endif
+
+#include <asm/bitops.h>
+#include <asm/smp.h>
+
+#include <linux/evl_log.h>
+
+
+static void mk_rec_header(struct posix_log_entry *rechdr,
+	posix_log_facility_t facility, int event_type,
+	posix_log_severity_t severity, size_t recsize,
+	uint recflags, int format);
+
+extern struct timezone sys_tz;
+
+#define EVL_BUF_SIZE (CONFIG_EVLOG_BUFSIZE * 1024)   /* EVL buffer size */
+#define EVL_BUF_FREESPACE (64*1024U) /* max free space reqd after buff */
+				    /* overrun to start writing events again. */
+
+/*
+ * This data structure describes the circular buffer that is written into
+ * by evl_kwrite_buf() and drained by evl_kbufread().
+ *
+ * bf_buf, bf_len, and bf_end are the start, length, and end of the buffer,
+ * and in the current implementation these remain constant.
+ *
+ * bf_tail advances as event records are logged to the buffer, and bf_head
+ * advances as records are drained from the buffer.  bf_curr is used
+ * internally by certain functions.  bf_dropped maintains a count of
+ * records that have been dropped due to buffer overrun.
+ */
+struct cbuf {
+	unsigned char	*bf_buf;	/* base buffer address */
+	unsigned int	bf_len;		/* buffer length */
+	unsigned int	bf_dropped;	/* (internal) dropped count */
+	unsigned char	*bf_head;	/* head-pointer for circ. buf */
+	unsigned char	*bf_tail;	/* tail-pointer for circ. buf */
+	unsigned char	*bf_curr;	/* (internal) current write ptr */
+	unsigned char	*bf_end;	/* end buffer address */
+};
+ 
+static unsigned char evl_buffer[EVL_BUF_SIZE + sizeof(long)];
+
+static struct cbuf evl_ebuf = {
+	evl_buffer,
+	EVL_BUF_SIZE,
+	0,
+	evl_buffer,
+	evl_buffer, 
+	evl_buffer,
+	evl_buffer + EVL_BUF_SIZE
+};
+
+/*
+ * This is for the serialisation of reads from the kernel buffer.
+ */
+static DECLARE_MUTEX(evl_read_sem);
+DECLARE_WAIT_QUEUE_HEAD(readq);
+spinlock_t ebuf_lock = SPIN_LOCK_UNLOCKED;
+
+/*
+ * FUNCTION     : cbufwrap
+ * Caller wants to write a chunk of size len bytes into the buffer starting at
+ * bf_curr.  If bf_curr is near the end of the buffer, then we may have to
+ * split the chunk so that some of it appears at the end of the buffer and
+ * the rest appears at the beginning.  dont_split_hdr=1 means the chunk is
+ * an entire record, and we're not allowed to split the record's header --
+ * we may have to leave unused space at the end of the buffer and start the
+ * record at the beginning.
+ *
+ * Return the location where the chunk should start, or NULL if there's
+ * no room for it (i.e., it would overrun the buffer's head pointer).
+ *
+ * ARGUMENTS    : bf_curr - where caller wants to put record
+ *              : len - total record size
+ *              : dont_split_hdr - 0 if it's OK to split the header, else 1
+ *
+ * RETURN       : where the record should be put, or NULL if no room
+ */
+static unsigned char *
+cbufwrap(unsigned char *bf_curr, size_t len, int dont_split_hdr)
+{
+	unsigned char *head, *end;
+	unsigned char *wrapbuf = bf_curr;
+
+	end = bf_curr + len;
+	head = evl_ebuf.bf_head;
+
+	if (bf_curr < head && end >= head) {
+		/* Insufficient free space in buffer; drop record. */
+		return NULL;
+	}
+	if (end > evl_ebuf.bf_end) {
+		/* end would be of end of buffer */
+		if (dont_split_hdr
+		    && bf_curr + REC_HDR_SIZE > evl_ebuf.bf_end) {
+			/* Start record at start of buffer. */
+			wrapbuf = evl_ebuf.bf_buf;
+		} else {
+			/* Split record */
+			len -= evl_ebuf.bf_end - bf_curr;
+		}
+
+		end = evl_ebuf.bf_buf + len;
+		if (end >= head) {
+			/* Insufficient free space in buffer; drop record. */
+			return NULL;
+		}
+	}
+	return wrapbuf;
+}
+
+/*
+ * FUNCTION     : cbufwrite
+ * Copy the len bytes starting at s into the buffer starting at bufp,
+ * splitting the data if we run off the end of the buffer.
+ *
+ * ARGUMENTS    : The pointer in cbuf to write at,
+ *                the buffer to write,
+ *                the number of bytes to write
+ * RETURN       : The pointer in cbuf at the end of the copied data
+ * NOTE
+ *      bf_head is owned by the drainer. bf_curr is allowed to be equal to
+ *      bf_head only when buffer is empty indicated by drainer. It is never
+ *      set to be equal by writer.
+ */
+static unsigned char *
+cbufwrite(unsigned char *bufp, unsigned char *s, size_t len)
+{
+	unsigned char *e;
+	size_t n, lw;
+
+	e = bufp + len;
+	n = len;
+
+	if (e > evl_ebuf.bf_end) {
+		lw = evl_ebuf.bf_end - bufp;
+		n -= lw;
+		e = evl_ebuf.bf_buf + n;
+		memcpy(bufp, s, lw);
+		memcpy(evl_ebuf.bf_buf, s + lw, n);
+		return e;
+	} else {
+		memcpy(bufp, s, n);
+		return (e == evl_ebuf.bf_end) ? evl_ebuf.bf_buf : e;
+	}
+}
+
+/*
+ * FUNCTION     : cbufptr
+ * Return cbuf_ptr + offset, taking possible wraparound into account.
+ *
+ * ARGUMENTS    : starting pointer in cbuf,
+ *                offset in bytes from pointer
+ * RETURN       : The pointer in circular buf that is offset bytes from
+ *                starting pointer.
+ */
+static unsigned char *
+cbufptr(unsigned char *cbuf_ptr, size_t offset)
+{
+	unsigned char *e;
+	size_t lw;
+
+	e = cbuf_ptr + offset;
+	if (e >= evl_ebuf.bf_end) {
+		lw = evl_ebuf.bf_end - cbuf_ptr;
+		e = evl_ebuf.bf_buf + (offset - lw);
+	}
+	return e;
+}
+
+/*
+ * FUNCTION     : copy_data_to_cbuf
+ * Copies the indicated record into the buffer at evl_ebuf.bf_curr.
+ * Assumes we've previously verified that the header won't be split.
+ * Updates evl_ebuf.bf_curr to point past the record just copied in.
+ *
+ * ARGUMENTS    : Record header
+ *                pointer to variable data
+ */
+static int
+copy_data_to_cbuf(struct posix_log_entry *rhdr, unsigned char *vbuf)
+{
+	memcpy(evl_ebuf.bf_curr, rhdr, REC_HDR_SIZE);
+	evl_ebuf.bf_curr += REC_HDR_SIZE;
+
+	if (rhdr->log_size > 0) {
+		evl_ebuf.bf_curr = 
+			cbufwrite(evl_ebuf.bf_curr, vbuf, rhdr->log_size);
+	}
+	
+	return 0;
+}
+
+/*
+ * EVL circular buffer had been full and caused later messages to be
+ * dropped. Now the buffer has space.  (Still it is better to identify the
+ * cause so it doesn't repeat. The buffer gets full if the rate of incoming
+ * messages is much higher than can be drained. This could happen if messages
+ * are repeated at an excessively high rate or the daemon in user-space is
+ * not running.)
+ *
+ * Now that we can log events again, log one giving the number of events
+ * dropped.
+ */
+static int
+log_dropped_recs_event(void)
+{
+	unsigned char sbuf[255];
+	struct posix_log_entry drechdr;
+	size_t vbuflen;
+	unsigned char *oldcur = evl_ebuf.bf_curr;
+
+	snprintf(sbuf, sizeof(sbuf), "%d event records dropped due to EVL buffer overflow.", 
+		evl_ebuf.bf_dropped);
+	evl_ebuf.bf_dropped = 0;
+	vbuflen = strlen(sbuf) + 1;
+	mk_rec_header(&drechdr, LOG_KERN, EVL_BUFFER_OVERRUN, LOG_INFO,
+		vbuflen, 0, POSIX_LOG_STRING);
+	evl_ebuf.bf_curr = cbufwrap(evl_ebuf.bf_curr, REC_HDR_SIZE+vbuflen, 1);
+	if (evl_ebuf.bf_curr != (unsigned char *)NULL) {
+		copy_data_to_cbuf(&drechdr, sbuf);
+		return 0;
+	} else {
+		/*
+		 * This shouldn't happen, since EVL_BUF_FREESPACE is much
+		 * bigger than the event we're logging here.
+		 */
+		evl_ebuf.bf_curr = oldcur;
+		return -1;
+	}
+}
+
+/*
+ * FUNCTION     : evl_check_buf
+ * ARGUMENTS    : NONE
+ * RETURN       : -1 for failure, ie. insufficient buffer space
+ *                 0 for success
+ * If buffer free space is greater than the applicable water-mark,
+ * returns 0.  If not, return -1.  Sets evl_buf.bf_curr to the location
+ * where the next record should go.
+ *
+ * Once the high water mark is hit and failure is returned (discarded
+ * messages) it sets a substantial low water mark before permitting
+ * messages to be buffered again.  It counts the number of discards
+ * in the meantime and reports them when restarted.  If the water
+ * marks were equivalent, then there could be a thrashing of stops
+ * and starts, making the discarded message reporting annoying.
+ *
+ */
+static int
+evl_check_buf(void)
+{
+	unsigned char *head, *tail;
+	size_t water_mark, avail;
+
+	head    = evl_ebuf.bf_head;
+	tail	= evl_ebuf.bf_tail;
+	avail   = (head <= tail) ?
+	      (evl_ebuf.bf_len - (tail - head)) :
+	      (head - tail);
+
+	if (evl_ebuf.bf_dropped != 0) {
+		/*
+		 * Still recovering from buffer overflow.
+		 * Apply the low water mark.
+		 */
+		water_mark = min(EVL_BUF_FREESPACE, evl_ebuf.bf_len / 2);
+	} else {
+		water_mark = REC_HDR_SIZE;
+	}
+
+	if (avail < water_mark) {
+		return -1;
+	}
+
+	/* There's enough free buffer space.  Return success. */
+	evl_ebuf.bf_curr = tail;
+	if (evl_ebuf.bf_dropped != 0) {
+		return log_dropped_recs_event();
+	}
+	return 0;
+}
+
+/*
+ * FUNCTION     : evl_getnext_rec
+ * ARGUMENTS    : rec is a pointer to the log event record.
+ *                The next record pointer mustn't be beyond tail.
+ * RETURN       : This function returns a pointer to the place to start the
+ *                next record in the circular buffer.  As a special case,
+ *                if rec is NULL, then the location of the first record at
+ *                or after bf_head is returned; else the record following
+ *                rec is returned.
+ */
+static unsigned char *
+evl_getnext_rec(unsigned char *rec, size_t recsize, unsigned char *tail)
+{
+	if (rec == NULL) {
+		rec = evl_ebuf.bf_head;
+	} else {
+		rec = cbufptr(rec, recsize);
+	}
+
+	if (rec == tail) {
+		return rec;
+	}
+
+	/* Check for wrap. */
+	if ((rec + REC_HDR_SIZE) > evl_ebuf.bf_end) {
+		rec = evl_ebuf.bf_buf;
+	}
+	return rec;
+}
+
+/*
+ * FUNCTION     : evl_kbufread - Used to read event records from the EVL
+ *                circular buffer.
+ * ARGUMENTS    : retbuf is a pointer to the buffer to be filled with the
+ *                event records.
+ *              : bufsize is length of the buffer allocated by the user.
+ * RETURN       : Number of bytes copied if read is successful, else -ve value.
+ *                event record and data to buffer.
+ */
+
+int
+evl_kbufread(unsigned char *retbuf, size_t bufsize)
+{
+	unsigned char *rec;
+	size_t rec_size;
+	int error = 0;
+	int retbuflen = 0;
+	unsigned char *tail, *buf = retbuf;
+
+	/*
+	 * the read request size must be at least rec_hdr_t size
+	 */
+	if (bufsize < REC_HDR_SIZE) {
+		return -EINVAL;
+	}
+	/* 
+	 * Serialize all reads, just in case someone got sneaky 
+	 */
+	error = down_interruptible(&evl_read_sem);
+	if (error == -EINTR) {
+		return -EINTR;
+	}
+	/*
+	 * Go to sleep if the buffer is empty.
+	 */
+	error = wait_event_interruptible(readq, 
+		(evl_ebuf.bf_head != evl_ebuf.bf_tail));
+	if (error) {
+		up(&evl_read_sem);
+		return error;
+	}
+	/*
+	 * Assemble message(s) into the user buffer, as many as will
+	 * fit.  On running out of space in the buffer, try to copy
+	 * the header for the overflowing message.  This means that
+	 * there will always be at least a header returned.  The caller
+	 * must compare the numbers of bytes returned (remaining) with
+	 * the length of the message to see if the entire message is
+	 * present.  A subsequent read will get the entire message,
+	 * including the header (again).
+	 */
+	tail = evl_ebuf.bf_tail;
+	rec = evl_getnext_rec(NULL, 0, tail);	/* typically evl_ebuf.bf_head */
+	if (rec == NULL) { 
+		/* Should not happen. Buffer must have atleast one record. */
+		error = -EFAULT;
+		goto out;
+	}
+
+	do {
+#if defined(__ia64__)
+		evl_buf_rec_t record;
+		memcpy(&record, rec, sizeof(evl_buf_rec_t));
+		rec_size = REC_HDR_SIZE + record.rechdr.log_size;
+#else
+		evl_buf_rec_t *p_rec;
+		p_rec = (evl_buf_rec_t *) rec;
+		rec_size = REC_HDR_SIZE + p_rec->rechdr.log_size;
+#endif
+
+		if (bufsize < REC_HDR_SIZE) {
+			/* user buffer is smaller than header */
+			break;
+		}
+		if (bufsize < rec_size) {
+			/* 
+			 * Copyout only the header 'cause user buffer can't
+			 * hold full record.
+			 */
+			error = copy_to_user(buf, rec, REC_HDR_SIZE);
+			if (error) {
+				error = -EFAULT;
+				break;
+			}
+			bufsize -= REC_HDR_SIZE;
+			retbuflen += REC_HDR_SIZE;
+			break;
+		}
+		if ((rec + rec_size) > evl_ebuf.bf_end) {
+			size_t lw = evl_ebuf.bf_end - rec;
+			error = copy_to_user(buf, rec, lw);
+			if (!error) {
+				error = copy_to_user(buf + lw, evl_ebuf.bf_buf, 
+					rec_size - lw); 
+			}
+		} else {
+			error = copy_to_user(buf, rec, rec_size);
+		}
+		if (error) {
+			error = -EFAULT;
+			break;
+		}
+		rec = evl_getnext_rec(rec, rec_size, tail);
+		buf += rec_size;
+		bufsize -= rec_size;
+		retbuflen += rec_size;
+	} while (rec != tail);
+
+	if (error == 0) {
+		evl_ebuf.bf_head = rec;
+		error = retbuflen;
+	}
+
+out:
+	up(&evl_read_sem);
+	return(error);
+}
+
+/*
+ * FUNCTION	: kwrite_buf
+ * Called by evl_kwrite_buf() to write to the buffer the event record
+ * consisting of rec_hdr and vardata.
+ *
+ * RETURN	: 0 on success, -ENOSPC on failure
+ *		On success evl_ebuf.bf_curr is updated to point just past
+ *		the event we just wrote to the buffer.
+ */
+static int
+kwrite_buf(struct posix_log_entry *rec_hdr, unsigned char *vardata)
+{
+	size_t recsize;
+	unsigned char *rec;
+	if (rec_hdr->log_size > POSIX_LOG_ENTRY_MAXLEN) {
+		rec_hdr->log_size = POSIX_LOG_ENTRY_MAXLEN;
+		rec_hdr->log_flags |= POSIX_LOG_TRUNCATE;
+	}
+	recsize = REC_HDR_SIZE + rec_hdr->log_size;
+	rec = cbufwrap(evl_ebuf.bf_curr, recsize, 1);
+	if (rec == (unsigned char *)NULL) {
+		return -ENOSPC;
+	}
+
+	evl_ebuf.bf_curr = rec;
+	copy_data_to_cbuf(rec_hdr, vardata);
+
+	/*
+	 * If the variable data is a truncated string, make sure it
+	 * ends with a null character.
+	 */
+	if ((rec_hdr->log_flags & POSIX_LOG_TRUNCATE) &&
+	    rec_hdr->log_format == POSIX_LOG_STRING) {
+		if (evl_ebuf.bf_curr == evl_ebuf.bf_buf) {
+			*(evl_ebuf.bf_end - 1) = '\0';
+		} else {
+			*(evl_ebuf.bf_curr - 1) = '\0';
+		}
+	}
+	return 0;
+}
+
+/*
+ * FUNCTION     : evl_kwrite_buf - Used to write kernel level messages.
+ * RETURN       : 0 if writing to buffer is successful, else -errno.
+ */
+
+static int
+evl_kwrite_buf(posix_log_facility_t    fac,
+		int                    ev_type,
+		posix_log_severity_t   sev,
+		int                    format,
+		unsigned char          *recbuf,
+		uint                   var_rec_len,
+		uint                   flags) 
+{
+	uint recflags = flags;
+	struct posix_log_entry rec_hdr;
+	int error = 0;
+	unsigned char *oldtail = evl_ebuf.bf_tail;
+		/* Used to wake the read call if it sleeps */ 
+	long iflags;	/* for spin_lock_irqsave() */
+
+	if (sev > LOG_DEBUG) {
+		return -EINVAL;
+	}
+	
+	recflags |= EVL_KERNEL_EVENT;   /* kernel mesagge */    
+	if (in_interrupt()) {
+		recflags |= EVL_INTERRUPT;
+	}
+	mk_rec_header(&rec_hdr, fac, ev_type, sev, var_rec_len, recflags,
+		format);
+	
+	spin_lock_irqsave(&ebuf_lock, iflags);
+	if (evl_check_buf() < 0) {
+		evl_ebuf.bf_dropped++;
+		spin_unlock_irqrestore(&ebuf_lock, iflags);
+		return -ENOSPC;
+	}
+
+	error = kwrite_buf(&rec_hdr, recbuf);
+
+	if (error == 0) {
+		evl_ebuf.bf_tail = evl_ebuf.bf_curr;
+		if ((evl_ebuf.bf_head == oldtail) &&
+		    (evl_ebuf.bf_head != evl_ebuf.bf_tail)) {
+			wake_up_interruptible(&readq);
+		}
+	} else if (error == -ENOSPC) {        
+		evl_ebuf.bf_dropped++;
+	}
+	spin_unlock_irqrestore(&ebuf_lock, iflags);
+	return error;
+}
+
+/*
+ *      This is the standard POSIX function for writing events to the event log, *      See event logging specification at:
+ *      http://evlog.sourceforge.net/linuxEvlog.html
+ */
+int posix_log_write(posix_log_facility_t facility, int event_type,
+                posix_log_severity_t severity, const void *buf,
+                size_t recsize, int format, unsigned int flags)
+{
+        int ret = 0;
+
+        if ((buf == (void *)NULL) && (recsize > 0)) {
+                return -EINVAL;
+        }
+        if (recsize == 0 && format != POSIX_LOG_NODATA) {
+                return -EINVAL;
+        }
+        if (format == POSIX_LOG_STRING) {
+                if (strlen((const char*)buf) != recsize-1) {
+                        return -EBADMSG;
+                }
+        }
+
+        ret = evl_kwrite_buf(facility, event_type, severity, format,
+                                (char *)buf, recsize, flags);
+
+        return ret;
+}
+
+/*
+ * buf is a buffer of size POSIX_LOG_ENTRY_MAXLEN.  It currently contains
+ * *reclen bytes.  Append as much of data to buf as will fit.  Set *reclen
+ * to what the updated size would be if buf were big enough.
+ */
+void
+evl_append_to_buf(char *buf, size_t *reclen, const void *data, size_t datasz)
+{
+        int copysz = (int) datasz;
+        int room = (int) POSIX_LOG_ENTRY_MAXLEN - (int) *reclen;
+        if (room > 0) {
+                if (copysz > room) {
+                        copysz = room;
+                }
+                (void) memcpy(buf + *reclen, data, copysz);
+        }
+        *reclen += datasz;
+}
+
+/*
+ * Append a string to the buffer.  If null == 1, we include the terminating
+ * null.  If the string extends over the end of the buffer, terminate the
+ * buffer with a null.
+ */
+void
+evl_append_string_to_buf(char *buf, size_t *reclen, const char *s, int null)
+{
+        size_t old_reclen = *reclen;
+        evl_append_to_buf(buf, reclen, s, strlen(s) + null);
+        if (*reclen > POSIX_LOG_ENTRY_MAXLEN
+            && old_reclen < POSIX_LOG_ENTRY_MAXLEN) {
+                buf[POSIX_LOG_ENTRY_MAXLEN-1] = '\0';
+        }
+}
+
+/*
+ * Note: This function is derived from vsnprintf() (see * lib/vsprintf.c),
+ * and should be kept in sync with that function.
+ */
+
+static int skip_atoi(const char **s)
+{
+        int i=0;
+
+        while (isdigit(**s))
+                i = i*10 + *((*s)++) - '0';
+        return i;
+}
+
+/*
+ * fmt points to the '%' in a printk conversion specification.  Advance
+ * fmt past any flags, width and/or precision specifiers, and qualifiers
+ * such as 'l' and 'L'.  Return a pointer to the conversion character.
+ * Stores the qualifier character (or -1, if there is none) at *pqualifier.
+ * *wp is set to flags indicating whether the width and/or precision are '*'.
+ * For example, given
+ *      %*.2lx
+ * *pqualifier is set to 'l', *wp is set to 0x1, and a pointer to the 'x'
+ * is returned.
+ *
+ * Note: This function is derived from vsnprintf() (see * lib/vsprintf.c),
+ * and should be kept in sync with that function.
+ */
+const char *
+parse_printf_fmt(const char *fmt, int *pqualifier, int *wp)
+{
+        int qualifier = -1;
+        *wp = 0;
+
+        /* process flags */
+        repeat:
+                ++fmt;          /* this also skips first '%' */
+                switch (*fmt) {
+                        case '-':
+                        case '+':
+                        case ' ':
+                        case '#':
+                        case '0':
+                                goto repeat;
+                }
+
+        /* get field width */
+        if (isdigit(*fmt))
+                skip_atoi(&fmt);
+        else if (*fmt == '*') {
+                ++fmt;
+                /* it's the next argument */
+                *wp |= 0x1;
+        }
+
+        /* get the precision */
+        if (*fmt == '.') {
+                ++fmt;
+                if (isdigit(*fmt))
+                        skip_atoi(&fmt);
+                else if (*fmt == '*') {
+                        ++fmt;
+                        /* it's the next argument */
+                        *wp |= 0x2;
+                }
+        }
+
+        /* get the conversion qualifier */
+        if (*fmt == 'h' || *fmt == 'l' || *fmt == 'L' || *fmt =='Z') {
+                qualifier = *fmt;
+                ++fmt;
+                if (qualifier == 'l' && *fmt == 'l') {
+                        qualifier = 'L';
+                        ++fmt;
+                }
+        }
+
+        *pqualifier = qualifier;
+        return fmt;
+}
+
+static void
+pack_args(char *buf, size_t *reclen, const char *fmt, va_list args)
+{
+#define COPYARG(type) { type v=va_arg(args,type); evl_append_to_buf(buf,reclen,&v,sizeof(v)); }
+	const char *s;
+	int qualifier;		/* 'h', 'l', or 'L' for integer fields */
+	                    /* 'z' support added 23/7/1999 S.H.    */
+	                    /* 'z' changed to 'Z' --davidm 1/25/99 */
+
+	for (; *fmt ; ++fmt) {
+		int wp = 0x0;
+		if (*fmt != '%') {
+			continue;
+		}
+
+		fmt = parse_printf_fmt(fmt, &qualifier, &wp);
+		if (wp & 0x1) {
+			/* width is '*' (next arg) */
+			COPYARG(int)
+		}
+		if (wp & 0x2) {
+			/* ditto precision */
+			COPYARG(int)
+		}
+
+		switch (*fmt) {
+			case 'c':
+				COPYARG(int)
+				continue;
+
+			case 's':
+				s = va_arg(args, char *);
+				evl_append_string_to_buf(buf, reclen, s, 1);
+				continue;
+
+			case 'p':
+				COPYARG(void*)
+				continue;
+
+			case 'n':
+				/* Skip over the %n arg. */
+				if (qualifier == 'l') {
+					(void) va_arg(args, long *);
+				} else if (qualifier == 'Z') {
+					(void) va_arg(args, size_t *);
+				} else {
+					(void) va_arg(args, int *);
+				}
+				continue;
+
+			case '%':
+				continue;
+
+				/* integer number formats - handle outside switch */
+			case 'o':
+			case 'X':
+			case 'x':
+			case 'd':
+			case 'i':
+			case 'u':
+				break;
+
+			default:
+				/* Bogus conversion.  Pass thru unchanged. */
+				if (*fmt == '\0')
+					--fmt;
+				continue;
+		}
+		if (qualifier == 'L') {
+			COPYARG(long long)
+		} else if (qualifier == 'l') {
+			COPYARG(long)
+		} else if (qualifier == 'Z') {
+			COPYARG(size_t)
+		} else if (qualifier == 'h') {
+			COPYARG(int)
+		} else {
+			COPYARG(int)
+		}
+	}
+}
+
+/*
+ * These buffers are currently used only by evl_fwd_printk(), and hence
+ * are protected by printk's logbuf_lock.  They're too big to be auto
+ * variables in evl_fwd_printk().
+ */
+static char prtk_argbuf[POSIX_LOG_ENTRY_MAXLEN];
+static size_t argbuf_idx;
+static char prtk_msgbuf[POSIX_LOG_ENTRY_MAXLEN + 1];
+static int msgbuf_idx = 0;
+/*
+ * msg is the message obtained by applying vsnprintf() to
+ * fmt and args.  (Caller does this anyway, so we don't have to.)
+ * Create and log a PRINTF-format event record whose contents are:
+ *	format string (possibly concatenated from multiple segments)
+ *	int containing args size
+ *	args
+ *	return address
+ *
+ * We consult msg only to determine the severity (e.g., "<1>") and whether
+ * we have a terminating newline.  If this message segment doesn't end
+ * in a newline, we save the fmt and args for concatenation with the next
+ * printk.
+ *
+ */
+int
+evl_fwd_printk(const char *fmt, va_list args, const char *msg)
+{
+	static int sev = -1;
+	int event_type;
+	int ret = 0;
+	int argsz;
+	int msglen = strlen(msg);
+	int last_segment = (msglen > 0 && msg[msglen-1] == '\n');
+
+	if (sev == -1) {
+		/* Severity not yet defined.  Must be a new message. */
+		sev = LOG_NOTICE;
+		if (msg[0] == '<'
+		    && msg[1] >= '0' && msg[1] <= '7'
+		    && msg[2] == '>') {
+			sev = msg[1] - '0';
+		}
+		msgbuf_idx = 0;
+		argbuf_idx = 0;
+	}
+
+	evl_append_string_to_buf(prtk_msgbuf, &msgbuf_idx, fmt, 0);
+	pack_args(prtk_argbuf, &argbuf_idx, fmt, args);
+	if (!last_segment) {
+		return 0;
+	}
+
+	/*
+	 * Message completed.  Change the terminating newline to a null.
+	 * We remove the terminating newline to increase flexibility when
+	 * formatting the record for viewing.
+	 */
+	if (msgbuf_idx <= POSIX_LOG_ENTRY_MAXLEN) {
+		prtk_msgbuf[msgbuf_idx-1] = '\0';
+	}
+
+	argsz = (int) argbuf_idx;
+	evl_append_to_buf(prtk_msgbuf, &msgbuf_idx, &argsz, sizeof(argsz));
+	evl_append_to_buf(prtk_msgbuf, &msgbuf_idx, prtk_argbuf, argbuf_idx);
+
+	if (msgbuf_idx > POSIX_LOG_ENTRY_MAXLEN) {
+		msgbuf_idx = POSIX_LOG_ENTRY_MAXLEN;
+	}
+
+	/* event type = CRC of format string */
+	event_type = (int) crc32(0, prtk_msgbuf, strlen(prtk_msgbuf));
+	
+	ret = evl_kwrite_buf(LOG_KERN, event_type, sev, POSIX_LOG_PRINTF,
+		prtk_msgbuf, msgbuf_idx, EVL_PRINTK);
+	sev = -1;
+	return ret;
+}
+
+/*
+ * FUNCTION             : mk_rec_header
+ * ARGS                 : rec_hdr - the record header stucture
+ *                      : facility -
+ *                      : event_type -
+ *                      : severity -
+ *                      : recsize
+ *                      : flags -
+ *                      : format - indicates string or binary format or no data
+ * RETURN       : void
+ */
+static void mk_rec_header(struct posix_log_entry *rec_hdr,
+		   posix_log_facility_t   facility,
+		   int                    event_type,
+		   posix_log_severity_t   severity,
+		   size_t                 recsize,
+		   uint                   flags,
+		   int            	  format)
+{
+
+	rec_hdr->log_size               =  recsize;
+	rec_hdr->log_format             =  format;
+	rec_hdr->log_event_type         =  event_type;
+	rec_hdr->log_facility           =  facility;
+	rec_hdr->log_severity           =  severity;
+	rec_hdr->log_uid                =  current->uid;
+	rec_hdr->log_gid                =  current->gid;
+	rec_hdr->log_pid                =  current->pid;
+	rec_hdr->log_pgrp               =  current->pgrp;
+	rec_hdr->log_flags              =  flags;
+	rec_hdr->log_thread             =  0;
+	rec_hdr->log_processor          =  smp_processor_id();
+
+	if (get_seconds() == 0) {
+		rec_hdr->log_flags |= EVL_INITIAL_BOOT_EVENT;
+	} else {
+#if defined(__i386__)
+		if (sys_tz.tz_minuteswest == 0) {
+			/* localtime */
+                        rec_hdr->log_flags |= EVL_KERNTIME_LOCAL;
+		}
+#endif
+	}
+	rec_hdr->log_time = CURRENT_TIME;
+}
+
+EXPORT_SYMBOL(posix_log_write);
diff -Naur linux.org/kernel/printk.c linux.kernel.patched/kernel/printk.c
--- linux.org/kernel/printk.c	Fri Apr 11 15:27:45 2003
+++ linux.kernel.patched/kernel/printk.c	Fri Apr 11 15:27:45 2003
@@ -83,6 +83,13 @@
 struct console_cmdline console_cmdline[MAX_CMDLINECONSOLES];
 static int preferred_console = -1;
 
+#ifdef CONFIG_EVLOG
+extern int evl_kbufread(char *, size_t);
+#endif
+#ifdef CONFIG_EVLOG_FWPRINTK
+extern int evl_fwd_printk(const char *fmt, va_list args, const char *msg);
+#endif
+
 /* Flag: console code may call schedule() */
 static int console_may_schedule;
 
@@ -154,6 +161,7 @@
  * 	7 -- Enable printk's to console
  *	8 -- Set level of messages printed to console
  *	9 -- Return number of unread characters in the log buffer
+ *     20 -- Read from event logging buffer 
  */
 int do_syslog(int type, char * buf, int len)
 {
@@ -268,6 +276,17 @@
 	case 9:		/* Number of chars in the log buffer */
 		error = log_end - log_start;
 		break;
+	case 20:
+#ifdef CONFIG_EVLOG
+		error = verify_area(VERIFY_WRITE, buf, len);
+		if (error) {
+			goto out;
+		}
+		error = evl_kbufread(buf, len);
+#else
+		error = -EIO;
+#endif
+		break;
 	default:
 		error = -EINVAL;
 		break;
@@ -408,6 +427,9 @@
 	/* Emit the output into the temporary buffer */
 	va_start(args, fmt);
 	printed_len = vsnprintf(printk_buf, sizeof(printk_buf), fmt, args);
+#ifdef CONFIG_EVLOG_FWPRINTK
+	(void) evl_fwd_printk(fmt, args, printk_buf);
+#endif
 	va_end(args);
 
 	/*

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 22:21 kernel support for non-English " Chuck Ebbert
@ 2003-04-11 22:53 ` Martin J. Bligh
  2003-04-12  7:55   ` John Bradford
  2003-04-12  7:48 ` John Bradford
  2003-04-14 11:40 ` Denis Vlasenko
  2 siblings, 1 reply; 137+ messages in thread
From: Martin J. Bligh @ 2003-04-11 22:53 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: linux-kernel

>> I thought you might be seriously in need of some mental evaluation
>> when you claimed that users "liked looking up error numbers in
>> manuals".
> 
> 
>  Not the looking up part, but that fact that the explanation
> for every single message the software could emit was available.
> 
>  Today it's all HTML documents or PDFs or something, but it's still
> a staggering amount of information.  I have ~300MB of Oracle
> documentation on one desktop, 6 of it server error messages alone.
> Every possible message is explained to some extent, except this one:

IMHO, it'd be better to just make the kernel error messages meaningful.
Keeping a large pile of documentation in sync with the source is
a PITA.

M.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-English user messages
  2003-04-11 20:49     ` Robert White
@ 2003-04-11 22:53       ` Riley Williams
  2003-04-15  3:44         ` Robert White
  0 siblings, 1 reply; 137+ messages in thread
From: Riley Williams @ 2003-04-11 22:53 UTC (permalink / raw)
  To: Robert White, Linux Kernel List

Hi Robert.

 > Actually, my final point had been that doing it inside the kernel
 > itself, or indeed inside klogd, was probably a very bad idea. If
 > the translation always happens after-the-fact based on properly
 > harvested message semantics then any segment of messages
 > distributed into this mailing list (among other uses) would be
 >
 > A)  Still in English.
 > B)  Translatable after the fact there too.
 >
 > Also after-the-fact translation makes the language translations a
 > scalar problem instead of a matrix one. That is, if you always
 > pass the message stream around in English (treat it like n opaque
 > source file) and then translate it as necessary, it will "always
 > work".
 >
 > If you try to do the translations at message generation time, then
 > the translation must be any-language-to-any-language capable during
 > post-even discussions. Not good.

I can see the points you're making, and that is precisely why I believe
that message codes would be required to implement this idea. As Linus
has vetoed the idea of having message codes in the kernel, I can't see
it ever coming to fruition.

 > Also, you will always have leakage as people add new strings to the
 > set.

That's the easiest aspect of dealing with it - the tool that generates
the language set to use just grabs the "English" language version for
any message codes not in the selected translation.

 > As for the #define issues, when you process the source tree to build the
 > source matrix you just "gcc -E file.c | collector" and now the printk
 > case you mention is handled. Any module designer who does uglier things
 > can make a dead-code procedure that expresses his possible output strings
 > for collection (if he cares.)

 > {Satire}

 > Speaking as an arrogant (U.S. of) American who knows that God(TradeMark,
 > all rights reserved) decreed that he never had to learn any language but
 > his own, I can honestly state, that it is nearly certain that you will
 > get no real support for the multi-language kernel out of a us
USAmericans.
 > We can't even get ourselves to write decent comments, and on the average,
 > we all secretly believe that if we just speak slowly enough everybody
 > really knows English. After all, that's how our condescending "wouldn't
 > want to fail Johnny, it would be bad for his self-image" public schools
 > taught us in the first place.... 8-)

Speaking as an amused (U.S. of) American, I long ago learned how to tell
when
somebody is speaking "God's Language"(tm) - that's simple to work out. After
all, the most likely people to speak "God's Language"(tm) are those that
have
just left His presence - the new born babies - so if we want to listen to
His
language, we just listen to them speak it. What could be simpler???

However, I understand "God's Language"(tm) is not currently understood well
enough by the kernel developers for any of them to translate the kernel
messages into it...

 > {/Satire}

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.471 / Virus Database: 269 - Release Date: 10-Apr-2003


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
@ 2003-04-11 22:21 Chuck Ebbert
  2003-04-11 22:53 ` Martin J. Bligh
                   ` (2 more replies)
  0 siblings, 3 replies; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-11 22:21 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel


> I thought you might be seriously in need of some mental evaluation
> when you claimed that users "liked looking up error numbers in
> manuals".


 Not the looking up part, but that fact that the explanation
for every single message the software could emit was available.

 Today it's all HTML documents or PDFs or something, but it's still
a staggering amount of information.  I have ~300MB of Oracle
documentation on one desktop, 6 of it server error messages alone.
Every possible message is explained to some extent, except this one:


-----------------------------------------------------------------------
ORA-00600 internal error code, arguments: [string], [string], [string],
                   [string], [string], [string], [string], [string]

Cause: This is the generic internal error number for Oracle program
exceptions. It indicates that a process has encountered a low-level,
unexpected condition.
<SNIP>
The first argument is the internal message number. Other arguments
are various numbers, names, and character strings. The numbers may
change meanings between different versions of Oracle. 

Action: Report this error to Oracle Customer Support after gathering
the following information:
<SNIP>
Note: The cause of this message may manifest itself as different errors
at different times. Be aware of the history of errors that occurred
before this internal error. 
-----------------------------------------------------------------------


which is currently pretty much the only explanation available for
a whole lot of Linux error messages. I can go read the source when e.g.
the md driver splats its internal status dumps all over the console
during array rebuild, but that doesn't help much.


> Whee. April first is long gone, but the jokers stay around.


 Our kind knows no season.


--
 "Let's fight till six, and then have dinner," said Tweedledum.
  --Lewis Carroll, _Through the Looking Glass_

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 21:04     ` Ruth Ivimey-Cook
@ 2003-04-11 21:31       ` Daniel Stekloff
  0 siblings, 0 replies; 137+ messages in thread
From: Daniel Stekloff @ 2003-04-11 21:31 UTC (permalink / raw)
  To: Ruth Ivimey-Cook, Riley Williams, Linux Kernel List, Robert White

On Friday 11 April 2003 02:04 pm, Ruth Ivimey-Cook wrote:
> At 10:21 11/04/2003, Riley Williams wrote:
> >It would also have to handle all the cases of...
> >
> >         #define CMD_PRINT(x...)   printk(KERN_INFO x)
> >
> >
> >         CMD_PRINT("This is some useless information");
>
> Personally, I feel there ought to be a standard set of these macros that
> can be used. Everyone keeps reinventing the same wheel :-(


We are trying to add standard logging macros to the kernel. Our first goal is 
to work with device driver writers to create useful macros that help prefix 
important information to messages logged from device drivers. We feel it 
would be useful for normal users, administrators, and service engineers to 
link a specific message with a specific device: so you can identify which 
device is erroring, for example. 

A first set of these macros is already in the 2.5 kernel. At the bottom of 
include/linux/device.h you'll find a set of dev_* macros:

/* debugging and troubleshooting/diagnostic helpers. */
#define dev_printk(level, dev, format, arg...)  \
        printk(level "%s %s: " format , (dev)->driver->name , (dev)->bus_id , 
## arg)

#ifdef DEBUG
#define dev_dbg(dev, format, arg...)            \
        dev_printk(KERN_DEBUG , dev , format , ## arg)
#else
#define dev_dbg(dev, format, arg...) do {} while (0)
#endif

#define dev_err(dev, format, arg...)            \
        dev_printk(KERN_ERR , dev , format , ## arg)
#define dev_info(dev, format, arg...)           \
        dev_printk(KERN_INFO , dev , format , ## arg)
#define dev_warn(dev, format, arg...)           \
        dev_printk(KERN_WARNING , dev , format , ## arg)


The idea behind the dev_printk macros is to identify the message with a 
specific device and the driver it manages. The dev_printk macro prints a 
corresponding driver name and bus id to identify the device and the driver. 
One can easily use that bus_id to search sysfs for the specific device the to 
which the message refers.

The dev_printk is a start. We could see separate macros for specific 
subsystems. Another example could be a netdev_printk macro that identifies 
not only the physical device by bus_id but adds the device interface 
information to the message as well. So, if you were working on a system with 
4 network devices, you'd know in the error message the network interface - 
eth3 - and which physical device - bus_id. 

Comments and suggestions are welcome. 

Thanks,

Dan

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11  9:21   ` kernel support for non-English " Riley Williams
  2003-04-11 20:49     ` Robert White
@ 2003-04-11 21:04     ` Ruth Ivimey-Cook
  2003-04-11 21:31       ` Daniel Stekloff
  1 sibling, 1 reply; 137+ messages in thread
From: Ruth Ivimey-Cook @ 2003-04-11 21:04 UTC (permalink / raw)
  To: Riley Williams, Linux Kernel List, Robert White

At 10:21 11/04/2003, Riley Williams wrote:
>It would also have to handle all the cases of...
>
>         #define CMD_PRINT(x...)   printk(KERN_INFO x)
>         :
>
>         CMD_PRINT("This is some useless information");


Personally, I feel there ought to be a standard set of these macros that 
can be used. Everyone keeps reinventing the same wheel :-(

Ruth 


^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-english user messages
       [not found] <A46BBDB345A7D5118EC90002A5072C780BEBA7DD@orsmsx116.jf.inte l.com>
@ 2003-04-11 20:55 ` Ruth Ivimey-Cook
  0 siblings, 0 replies; 137+ messages in thread
From: Ruth Ivimey-Cook @ 2003-04-11 20:55 UTC (permalink / raw)
  To: Perez-Gonzalez, Inaky, 'Chuck Ebbert', 'linux-kernel'

At 22:20 10/04/2003, Perez-Gonzalez, Inaky wrote:
> > >Ruth Ivimey-Cook wrote:
> > >> results in the following in the kernel buffer:
> > >> "%s: name %p is %d\n", "stringval", 0x4790243, 44
> > > Debugging a non-klogd enabled kernel would be a pain
> >  Why?  Shouldn't it be easy to fix dmesg so it unmangles the output?
>s/non-klogd enabled/dmesg/
>Same thing - what I mean is that if you don't have some automatic
>means to recompose the messages, reading the direct output of
>the console (as sometimes you have to), becomes a mess.

What I was trying to suggest is that a new kernel thread was created that 
could recompose the messages and push them into the buffer that dmesg reads 
(is that /dev/kmsg?). Thus, the old dmesg and anything else would work fine.

However, for internationalization, another (user-space) process could send 
a signal to the kernel thread to say "stop that", take over the reading of 
unexpended messages and use getmsg() type mechanisms to push messages into 
the dmesg buffer. It might be nice if the kernel thread could be reawoken 
should the user-space process die, just in case (using SIGCHLD?)


Someone else mentioned they didn't like seeing loads of messages emitted. I 
do like it, as it means I can be sure that the OS has booted ok. However, 
how about enforcing the log level stuff more, so that a printk without a 
KERN_ log-level was ignored, and enabling a kernel-command line parameter 
that set the default log level of console messages. So if you did "vmlinux 
loglevel=crit" then you only get critical notices?

If we deprecated printk in favour of macros, e.g.:
#define printk_info(x, ...)  printk(KERN_INFO ## x, ...)

then it would be (fairly) easy to drop all the "info" level printk's from 
the kernel build, shouls the builder wish.

HTH,

Ruth 


^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-English user messages
  2003-04-11  9:21   ` kernel support for non-English " Riley Williams
@ 2003-04-11 20:49     ` Robert White
  2003-04-11 22:53       ` Riley Williams
  2003-04-11 21:04     ` Ruth Ivimey-Cook
  1 sibling, 1 reply; 137+ messages in thread
From: Robert White @ 2003-04-11 20:49 UTC (permalink / raw)
  To: Riley Williams, Linux Kernel List

Actually, my final point had been that doing it inside the kernel itself, or
indeed inside klogd, was probably a very bad idea.  If the translation
always happens after-the-fact based on properly harvested message semantics
then any segment of messages distributed into this mailing list (among other
uses) would be

A)  Still in English.
B)  Translatable after the fact there too.

Also after-the-fact translation makes the language translations a scalar
problem instead of a matrixed one.  That is, if you always pass the message
stream around in English (treat it like n opaque source file) and then
translate it as necessary, it will "always work".

If you try to do the translations at message generation time, then the
translation must be any-language-to-any-language capable during post-even
discussions.  Not good.

Also, you will always have leakage as people add new strings to the set.

As for the #define issues, when you process the source tree to build the
source matrix you just "gcc -E file.c | collector" and now the printk case
you mention is handled.  Any module designer who does uglier things can make
a dead-code procedure that expresses his possible output strings for
collection (if he cares.)

{Satire}
Speaking as an arrogant (U.S. of) American who knows that God(TradeMark, all
rights reserved) decreed that he never had to learn any language but his
own, I can honestly state, that it is nearly certain that you will get no
real support for the multi-language kernel out of a us USAmericans.  We
can't even get ourselves to write decent comments, and on the average, we
all secretly believe that if we just speak slowly enough everybody really
knows English.  After all, that's how our condescending "wouldn't want to
fail Johnny, it would be bad for his self-image" public schools taught us in
the first place.... 8-)
{/Satire}

Rob.

-----Original Message-----
From: Riley Williams [mailto:Riley@Williams.Name]
Sent: Friday, April 11, 2003 2:21 AM
To: Linux Kernel List; Robert White
Subject: Re: kernel support for non-English user messages


Hi Robert.

 > It is tautologically true that every printk starts with a format
 > string, and that "really" the kernel has no business "switching
 > languages" on the fly. That is, like selecting the chipset, the
 > language the kernel should express it self ought to be selected
 > at compile time.

I can certainly accept such an argument for a single system. The
problem I have is with people then posting their errors on here
with the messages in a language that none of the maintainers on
here understands - how are we then expected to help them?

It is because of this requirement that I believe that message codes
in some form are unavoidable - at least with message codes, one
can look them up and find the version of the message translated
into one's own language. However, Linus has vetoed the idea of
putting such codes into the kernel in any form, and that makes the
whole idea a non-starter in any form.

Personally, I'm willing to discuss this issue and see what sort of
ideas we can come up with, and what problems each idea may have.

 > In essence, the translations have to be done earlier in the
 > process instead of later. Having or needing a tool to read the
 > log won't help someone trying to diagnose a problem where a tool
 > isn't in place and the storage requirements for after-the-fact
 > to see and use the output become unreasonable. (It's just not
 > telnet/shell friendly.)

Agreed.

 > Consider a tool that scans any source file and collects up the
 > literal strings of every printk encountered and tosses them into
 > a static array...
 >
 >	"CHAR_TYPE * KernelMessage[] = { "whatever", "whatever"...};"
 >
 > ...then replaces...
 >
 >	printk("whatever",...);
 >
 > ...with...
 >
 >	printk(KernelMessage[0],...);

It would also have to handle all the cases of...

	#define CMD_PRINT(x...)   printk(KERN_INFO x)

			:

	CMD_PRINT("This is some useless information");

...that are spread amongst various subsystems. Personally, I'd prefer
to see macros like that replaced with the printk calls directly, but
that's up to the individual subsystem maintainers.

The simple way to do this would be to insert the kernel message tool
into the compilation process immediately after the macro expansion
tool has run, as all of the above macros would have been expanded at
that time. However, this requires that the intermediate files are
all saved as part of the compilation process, otherwise this tool
would have no means of accessing the expanded macros.

 > subsequent runs of this theoretical tool will take any new prink(s)
 > found and add them to the list. For completeness, any KernelMessage
 > subscripts never used (cause the printk was removed) would get
 > burped out of the sequence at re-expression time.

We need certain guarantees for this system to be usable. See my reply
to Alan Cox on this subject for details.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.471 / Virus Database: 269 - Release Date: 10-Apr-2003


^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-english user messages
@ 2003-04-11 20:02 Perez-Gonzalez, Inaky
  0 siblings, 0 replies; 137+ messages in thread
From: Perez-Gonzalez, Inaky @ 2003-04-11 20:02 UTC (permalink / raw)
  To: 'Valdis.Kletnieks@vt.edu', 'Shaya Potter'
  Cc: 'John Bradford', 'Alan Cox',
	'root@chaos.analogic.com', 'Frank Davis',
	'Linux Kernel Mailing List'


> 3) Version a 500 megabyte file.  Change one block.  Do it a few more
times.
> Are you better off copying the whole file (which bloats your disk usage
and
> kills your I/O bandwidth), or keeping deltas (the list of allocated blocks
could be
> almost identical except for the replaced/rewritten blocks).  However, this
DOES
> make doing an fsck() a *lot* more interesting - is a block allocated to
multiple
> files in error or not?

For this I would yield to a mechanism similar to COW, block you modify,
block you copy ... it would impose some restrictions here and there, 
but it'd work, I'd say - still it is fun for fsck(), as you are changing
some semantics, but it'd be interesting.

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 16:57 Chuck Ebbert
  2003-04-11 17:38 ` Richard B. Johnson
@ 2003-04-11 18:10 ` Matti Aarnio
  1 sibling, 0 replies; 137+ messages in thread
From: Matti Aarnio @ 2003-04-11 18:10 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: linux-kernel

On Fri, Apr 11, 2003 at 12:57:28PM -0400, Chuck Ebbert wrote:
> Alan Cox wrote:
... 
>   I still see some problems...
>   For one, there are 131 instances of:
>       printk("%s\n", blurb);
> 
> in various forms in 2.5.66.  Besides possible ritual immolation of
> those responsible for such things, something would have to be done
> about them.

Think again.  In case the "blurp" COULD have "%" in them...

>   Another problem is the one of getting that text onto the console
> in readable form. The only thing I can think of is have a two-stage
> process where printk puts the data into the log buffer as
> zero-terminated strings and then the console write routines format
> it for display.  They'd probably need their own buffers to do that.

Many of kernel's terse messages do need small encyclopedic articles
to explain them.  Present  gobble-de-gook  can not be made clear by
merely supplying  l10n  translations of them to other gobble-de-gook.

Having ANCIENT STYLE numeric message code references will help users
to find definitive explanations of them.   "My machine said: 
'1-00234-0627 eth0 link down'  and  then it said: '1-00234-0626 eth0 link up'"
(Where initial digit is severity qualifier, then subsystem id, and
finally codepoint within subsystem.  All within 32-bit integer.)
(And probably base64-ish presentation in dmesg buffer, not base10..)

Some tool can produce HTML hyperlinked presentation of the messages
with colour coding telling message classifications as text line backgrounds:
  green:  info/chatty, can ignore
  blue:   something notable happened (like linkstate jumps)
  yellow: something possibly serious
  red:    something definitely serious

at the same time the tool can produce hyperlinks with user's language
preferences (picked from environment/desktop parameters), and point
all that to some site with e.g. a twiki to accumulate documentation.
Vendors could also pull database snapshots into those tools.


That message-code style was introduced, when machines had very little
memory,  but style being in use from the dawn of computing is not
a good reason to shun it.  It really has benefits.


> > %s: went up in flames\n\0eth0\0\0
> 
>   Is that "\n" an actual ASCII newline or the printk escape sequence?

The backslash is not "printk escape".  It is C-string compilation 
notation.

/Matti Aarnio

^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-English user messages
  2003-04-11 16:57 Chuck Ebbert
@ 2003-04-11 17:38 ` Richard B. Johnson
  2003-04-11 18:10 ` Matti Aarnio
  1 sibling, 0 replies; 137+ messages in thread
From: Richard B. Johnson @ 2003-04-11 17:38 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: Alan Cox, linux-kernel

On Fri, 11 Apr 2003, Chuck Ebbert wrote:

> Alan Cox wrote:
>
>
> > You are right about needing to log parameters, but given a log line
> > of the form
> >
> > %s: went up in flames\n\0eth0\0\0
> >
> > that can be handled by the log viewer
>
>
>   I still see some problems...
>
>   For one, there are 131 instances of:
>
>       printk("%s\n", blurb);

[SNIPPED....]

There are 48,038 printk statements in linux-2.4.20. The text portion
of those statements comprises 307,136 bytes, excluding modules!

This print-your-way code has more ASCII than MBASIC. It is
patently absurd and some people are trying to legitimize this
text bloat with a translation utility. Fork the kernel and
make it text-based if you want, but we need to remove most of
this text on the standard kernel, not make it somehow seem
right. It is wrong, just plain wrong, and it's getting worse
as time goes on.

Every one of those printk-drivers should have an ioctl() so
that some user-mode program can check on its health, how many
SCSI disks got found, what the Ethernet parameters are, etc.
This is not something that should be printed on the screen
every time the machine boots for the one-time-out-of-1000
that a disk didn't come on-line or the network didn't come
up. Most all of the error reporting within the kernel is being
done without regard to what used to be called "good standards
of engineering practice".

BSD also has this problem but you would expect that from
students because they become amazed as their driver starts
to work and they proudly print every intermediate step in
the initialization. Professionals should know better and
do better work.

Properly running software is indistinguishable from magic
and it is completely invisible to the user.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-English user messages
@ 2003-04-11 16:57 Chuck Ebbert
  2003-04-11 17:38 ` Richard B. Johnson
  2003-04-11 18:10 ` Matti Aarnio
  0 siblings, 2 replies; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-11 16:57 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel

Alan Cox wrote:


> You are right about needing to log parameters, but given a log line
> of the form
>
> %s: went up in flames\n\0eth0\0\0
>
> that can be handled by the log viewer


  I still see some problems...

  For one, there are 131 instances of:

      printk("%s\n", blurb);

in various forms in 2.5.66.  Besides possible ritual immolation of
those responsible for such things, something would have to be done
about them.

  Another problem is the one of getting that text onto the console
in readable form. The only thing I can think of is have a two-stage
process where printk puts the data into the log buffer as
zero-terminated strings and then the console write routines format
it for display.  They'd probably need their own buffers to do that.


> %s: went up in flames\n\0eth0\0\0


  Is that "\n" an actual ASCII newline or the printk escape sequence?



--
 "Let's fight until six, and then have dinner," said Tweedledum.
 --Lewis Carroll, _Through the Looking Glass_

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 13:17 kernel support for non-English " Chuck Ebbert
  2003-04-11 13:40 ` John Bradford
  2003-04-11 14:37 ` Richard B. Johnson
@ 2003-04-11 16:00 ` Linus Torvalds
  2003-04-12  8:22 ` Kai Henningsen
  3 siblings, 0 replies; 137+ messages in thread
From: Linus Torvalds @ 2003-04-11 16:00 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: linux-kernel


On Fri, 11 Apr 2003, Chuck Ebbert wrote:
> 
>  (Of course there were drawbacks, too... when the leather belt driving
> the Difference Engine broke, for example, it was every man for himself!)

Before that last thing, you had me really worried for a while. I thought 
you might be seriously in need of some mental evaluation when you claimed 
that users "liked looking up error numbers in manuals".

Whee. April first is long gone, but the jokers stay around.

		Linus


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
@ 2003-04-11 14:52 Paolo Ciarrocchi
  0 siblings, 0 replies; 137+ messages in thread
From: Paolo Ciarrocchi @ 2003-04-11 14:52 UTC (permalink / raw)
  To: linux-kernel; +Cc: john

>On a related note, if we are going to make a dmesg interpreter and
>translator, could we include the ability to generate a kernel .config
>from the boot time output?  Note, I don't mean re-create the .config
>that the kernel was compiled with, but something like NetBSD, (at
>least), which lets you boot with a kernel that has drivers that you
>don't need, and generate a config file which will compile a kernel
>which contains only those that are actually needed.

Yes please, it is a 'nice to have stuff'.

Ciao,
       Paolo


-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 13:11         ` Alan Cox
@ 2003-04-11 14:48           ` John Bradford
  0 siblings, 0 replies; 137+ messages in thread
From: John Bradford @ 2003-04-11 14:48 UTC (permalink / raw)
  To: Alan Cox; +Cc: John Bradford, Riley Williams, Linux Kernel Mailing List

> > Wouldn't we be better off just more fully documenting the English
> > error messages, though, and possibly translating that explaination
> > document in to as many languages as possible?  A lot of people search
> > for error messages strings in the LKML archives, and variations of the
> > same string will hinder this.
> 
> I don't think thats going to happen much. And to document them you have
> enumerate them so its still the same problem space strangely enough

I don't mean document them within the source, I mean a separate
document, (distributed with the source), that people can refer to to
find out what errors really mean.  That solves the verbose/non
versbose and translation problems.  Users simply do a substring search
of the manual for the error they're getting, and get an explaination
in any language that manual has been translated in to.  It doesn't
have to be limited to errors, either, there are a lot of undocumented
informational messages in the kernel, too.

I'd be happy to maintain such a document, but there doesn't seem much
interest in it, and I can't see why.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 13:17 kernel support for non-English " Chuck Ebbert
  2003-04-11 13:40 ` John Bradford
@ 2003-04-11 14:37 ` Richard B. Johnson
  2003-04-11 16:00 ` Linus Torvalds
  2003-04-12  8:22 ` Kai Henningsen
  3 siblings, 0 replies; 137+ messages in thread
From: Richard B. Johnson @ 2003-04-11 14:37 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: Linus Torvalds, linux-kernel

On Fri, 11 Apr 2003, Chuck Ebbert wrote:

> Linux Torvalds wrote:
>
>
> > I've used VMS, and error code number encoding is a total heap of crap.
>
[SNIPPED...]

>
> (Of course there were drawbacks, too... when the leather belt driving
> the Difference Engine broke, for example, it was every man for himself!)
>

You think you are kidding? The main hard disk on one of our VAX/11-750
was belt-driven. I think it was a RA50?? Anyway, it consisted of
a 55 pound sealed aluminum casting with fins (HDA), that a technician
would roll in using a refrigerator dolly. It had a pulley on it's
bottom that was fit into a belt to spin it up. The motor sounded
like a vacuum-cleaner motor, probably made by Hoover.

Wmmm.
$ ls /  # "DIR"
%DIRECT-W-NOFILES, no files found

Remember versioned files? What would Unix do with....

$ renam *.*;* *.*;1

$ ls
  *.*;1
$
You get left with one file called *.*;1  -- nice!

I did like....
$ set proc/priv=all
$ @sys$system:shutdown

It was almost as amazing as `init 0` on Red-Hat distributions....

> --
>  Chuck

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 13:17 kernel support for non-English " Chuck Ebbert
@ 2003-04-11 13:40 ` John Bradford
  2003-04-16  1:59   ` Gerrit Huizenga
  2003-04-11 14:37 ` Richard B. Johnson
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 137+ messages in thread
From: John Bradford @ 2003-04-11 13:40 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: Linus Torvalds, linux-kernel

> > I've used VMS, and error code number encoding is a total heap of crap.
> 
>  Maybe for developers, but users like it.  I can still remember back in
> the Old Days, taking those error codes and looking them up in something
> called a "manual" where there was a coherent explanation of
> what had gone wrong and even suggestions on what to do about it.

Well, you don't need error codes to make a comprehensive manual, you
can just look up the English error message, and get a detailed
explaination of it, in any language.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 12:16     ` Alan Cox
@ 2003-04-11 13:39       ` John Bradford
  2003-04-11 13:11         ` Alan Cox
  0 siblings, 1 reply; 137+ messages in thread
From: John Bradford @ 2003-04-11 13:39 UTC (permalink / raw)
  To: Alan Cox; +Cc: Riley Williams, Linux Kernel Mailing List

> >  1. If the printk() messages are internationalised, we are going to
> >     see log extracts posted here in various languages, including some
> >     that the relevant maintainers don't understand. To stand any
> >     realistic chance of dealing with the resultant bug reports, we
> >     need to include the message code in the report so we can just
> >     feed the various reports through a tool that translates them into
> >     our preferred language.
> 
> Providing the viewer is translating the originals always exist. Indeed
> you can do
> 
> 	LANG=es view-logs
> 	LANG=ru view-logs
> 	...
> 
> You can have sysadmins with no common language("not a recommended
> configuration" ;))
> 
> You are right about needing to log parameters, but given a log line
> of the form
> 
> %s: went up in flames\n\0eth0\0\0
> 
> that can be handled by the log viewer

Wouldn't we be better off just more fully documenting the English
error messages, though, and possibly translating that explaination
document in to as many languages as possible?  A lot of people search
for error messages strings in the LKML archives, and variations of the
same string will hinder this.

On a related note, if we are going to make a dmesg interpreter and
translator, could we include the ability to generate a kernel .config
from the boot time output?  Note, I don't mean re-create the .config
that the kernel was compiled with, but something like NetBSD, (at
least), which lets you boot with a kernel that has drivers that you
don't need, and generate a config file which will compile a kernel
which contains only those that are actually needed.

John.

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
@ 2003-04-11 13:17 Chuck Ebbert
  2003-04-11 13:40 ` John Bradford
                   ` (3 more replies)
  0 siblings, 4 replies; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-11 13:17 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

Linux Torvalds wrote:


> I've used VMS, and error code number encoding is a total heap of crap.


 Maybe for developers, but users like it.  I can still remember back in
the Old Days, taking those error codes and looking them up in something
called a "manual" where there was a coherent explanation of
what had gone wrong and even suggestions on what to do about it.

 (Of course there were drawbacks, too... when the leather belt driving
the Difference Engine broke, for example, it was every man for himself!)

--
 Chuck

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-11 13:39       ` John Bradford
@ 2003-04-11 13:11         ` Alan Cox
  2003-04-11 14:48           ` John Bradford
  0 siblings, 1 reply; 137+ messages in thread
From: Alan Cox @ 2003-04-11 13:11 UTC (permalink / raw)
  To: John Bradford; +Cc: Riley Williams, Linux Kernel Mailing List

On Fri, 2003-04-11 at 14:39, John Bradford wrote:
> Wouldn't we be better off just more fully documenting the English
> error messages, though, and possibly translating that explaination
> document in to as many languages as possible?  A lot of people search
> for error messages strings in the LKML archives, and variations of the
> same string will hinder this.

I don't think thats going to happen much. And to document them you have
enumerate them so its still the same problem space strangely enough



^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-English user messages
  2003-04-11  9:21   ` kernel support for non-English " Riley Williams
@ 2003-04-11 12:16     ` Alan Cox
  2003-04-11 13:39       ` John Bradford
  0 siblings, 1 reply; 137+ messages in thread
From: Alan Cox @ 2003-04-11 12:16 UTC (permalink / raw)
  To: Riley Williams; +Cc: Linux Kernel Mailing List

On Fri, 2003-04-11 at 10:21, Riley Williams wrote:
>  1. If the printk() messages are internationalised, we are going to
>     see log extracts posted here in various languages, including some
>     that the relevant maintainers don't understand. To stand any
>     realistic chance of dealing with the resultant bug reports, we
>     need to include the message code in the report so we can just
>     feed the various reports through a tool that translates them into
>     our preferred language.

Providing the viewer is translating the originals always exist. Indeed
you can do

	LANG=es view-logs
	LANG=ru view-logs
	...

You can have sysadmins with no common language("not a recommended
configuration" ;))

You are right about needing to log parameters, but given a log line
of the form

%s: went up in flames\n\0eth0\0\0

that can be handled by the log viewer


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
       [not found]           ` <20030410202016$7d48@gated-at.bofh.it>
@ 2003-04-11 11:29             ` Tim Connors
  0 siblings, 0 replies; 137+ messages in thread
From: Tim Connors @ 2003-04-11 11:29 UTC (permalink / raw)
  To: linux-kernel

In linux.kernel, you wrote:
>>>>>> " " == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
>      > VMS is alive and well, even though Compaq tried to kill
>      > it. There is a lot of anti-VMS stuff in the Unix world mostly
>      > coming from the _horrible_ command line and other bad early
>      > memories. There is also a hell of a lot of really cool stuff
>      > under that command line we could and should learn from.
> 
> The day I wake up and see one of my processes in the "RWAST" state is
> the day I move to a BSD clone 8-)

Er, Only used VMS once, but you mean like a process stuck in a D
state?

Happens often with NFS ;)

-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/

double value;                /* or your money back! */
short changed;               /* so triple your money back! */
             -- Larry Wall in cons.c from the perl source code

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
@ 2003-04-11 10:10 Chuck Ebbert
  0 siblings, 0 replies; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-11 10:10 UTC (permalink / raw)
  To: DevilKin, linux-kernel


>linux dmesg=verbose
>
>and
>
>linux dmesg=quiet


 You really need "dmesg=normal" as well, unless you are calling the
current behavior verbose.  After seeing FreeBSD in bootverbose
mode, I wouldn't...

--
 Chuck
 I am not a number!

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-English user messages
  2003-04-10 20:41 ` Robert White
@ 2003-04-11  9:21   ` Riley Williams
  2003-04-11 20:49     ` Robert White
  2003-04-11 21:04     ` Ruth Ivimey-Cook
  0 siblings, 2 replies; 137+ messages in thread
From: Riley Williams @ 2003-04-11  9:21 UTC (permalink / raw)
  To: Linux Kernel List, Robert White

Hi Robert.

 > It is tautologically true that every printk starts with a format
 > string, and that "really" the kernel has no business "switching
 > languages" on the fly. That is, like selecting the chipset, the
 > language the kernel should express it self ought to be selected
 > at compile time.

I can certainly accept such an argument for a single system. The
problem I have is with people then posting their errors on here
with the messages in a language that none of the maintainers on
here understands - how are we then expected to help them?

It is because of this requirement that I believe that message codes
in some form are unavoidable - at least with message codes, one
can look them up and find the version of the message translated
into one's own language. However, Linus has vetoed the idea of
putting such codes into the kernel in any form, and that makes the
whole idea a non-starter in any form.

Personally, I'm willing to discuss this issue and see what sort of
ideas we can come up with, and what problems each idea may have.

 > In essence, the translations have to be done earlier in the
 > process instead of later. Having or needing a tool to read the
 > log won't help someone trying to diagnose a problem where a tool
 > isn't in place and the storage requirements for after-the-fact
 > to see and use the output become unreasonable. (It's just not
 > telnet/shell friendly.)

Agreed.

 > Consider a tool that scans any source file and collects up the
 > literal strings of every printk encountered and tosses them into
 > a static array...
 >
 >	"CHAR_TYPE * KernelMessage[] = { "whatever", "whatever"...};"
 >
 > ...then replaces...
 >
 >	printk("whatever",...);
 >
 > ...with...
 >
 >	printk(KernelMessage[0],...);

It would also have to handle all the cases of...

	#define CMD_PRINT(x...)   printk(KERN_INFO x)

			:

	CMD_PRINT("This is some useless information");

...that are spread amongst various subsystems. Personally, I'd prefer
to see macros like that replaced with the printk calls directly, but
that's up to the individual subsystem maintainers.

The simple way to do this would be to insert the kernel message tool
into the compilation process immediately after the macro expansion
tool has run, as all of the above macros would have been expanded at
that time. However, this requires that the intermediate files are
all saved as part of the compilation process, otherwise this tool
would have no means of accessing the expanded macros.

 > subsequent runs of this theoretical tool will take any new prink(s)
 > found and add them to the list. For completeness, any KernelMessage
 > subscripts never used (cause the printk was removed) would get
 > burped out of the sequence at re-expression time.

We need certain guarantees for this system to be usable. See my reply
to Alan Cox on this subject for details.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.471 / Virus Database: 269 - Release Date: 10-Apr-2003


^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-English user messages
  2003-04-10 19:01 ` Alan Cox
@ 2003-04-11  9:21   ` Riley Williams
  2003-04-11 12:16     ` Alan Cox
  0 siblings, 1 reply; 137+ messages in thread
From: Riley Williams @ 2003-04-11  9:21 UTC (permalink / raw)
  To: Alan Cox; +Cc: Linux Kernel Mailing List

Hi Alan.

 >> If we use 32-bit hash codes, there's a real chance of different
 >> messages

 > There are less than 65536 files each of which is less than 65536
 > lines long, so it seems that a properly chosen automated index
 > ought to be collision free ?

Some thoughts on that:

 1. If the printk() messages are internationalised, we are going to
    see log extracts posted here in various languages, including some
    that the relevant maintainers don't understand. To stand any
    realistic chance of dealing with the resultant bug reports, we
    need to include the message code in the report so we can just
    feed the various reports through a tool that translates them into
    our preferred language.

 2. For the above to work, we need the following guarantees:

     a. A particular message code always refers to the same message.

     b. A particular message is always referred to by the same
        message code.

 3. To obtain these guarantees, we need to ensure that the translation
    tool supplied with any particular kernel can handle all message
    codes from that kernel or from any earlier kernel in its direct
    ancestry. We thus can't reuse message codes once issued.

 4. In some languages, the parameters will need to be specified in a
    different order to the English order.

 5. We wish to keep the kernel size to a minimum.

The combination of the above points would lead me to suggest the
following design:

 1. The printk() function must NEVER be on the RHS of any #define
    statement. Many source files currently do this, and it kills any
    hope of an automated tool going through the kernel sources and
    allocating message numbers, irrespective of the numbering method
    chosen.

 2. Given the above, it would be possible to change the compilation
    sequence such that the message indexing tool runs first and
    pre-processes each printk() call to replace the format string with
    an index into a table of message formats. This table would contain
    in each row first the message code allocated to that row, then the
    format string, and finally a key to the parameter order to be used.
    The table generated would thus be the English language file, and
    would be generated such that any existing messages therein were
    reused. This would have the benefit that where any particular
    message format occurs multiple times, they would be merged.

 3. Given all of the above, a new printk() function would be written
    to index into the table and pick out the relevant row, then to
    produce a call to the current printk() function (renamed as
    printk2() or whatever) with its parameters sorted into the order
    specified by the final field in the table.

 4. Where functions will be called prior to such internationalisations
    being available, they would call the printk2() function directly,
    and the message indexing tool would be designed to ignore such
    calls when doing its parsing.

 5. The next step of the compilation would process the files produced
    by this tool rather than the original kernel sources.

This would then lead to the actual messages existing in a separate
directory in the kernel source tree with the `make *config` process
allowing one to select the appropriate language to be used, and
auto-indexing the available languages (not hard to do). The compilation
would then run a separate tool that created a *.h file with the relevant
version of the table for that particular compilation.

One detail that would need to be handled is this: If the selected
language file did not contain an entry for a particular message code,
the entry for that message code would need to be extracted from the
English language file. To help with translation, it should produce a
report stating which message codes it had to do that for.

Also, the table would want to be sorted by message number to speed up
access to the individual messages.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.471 / Virus Database: 269 - Release Date: 10-Apr-2003


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 22:06 ` Andreas Dilger
@ 2003-04-11  7:38   ` Ville Herva
  0 siblings, 0 replies; 137+ messages in thread
From: Ville Herva @ 2003-04-11  7:38 UTC (permalink / raw)
  To: Perez-Gonzalez, Inaky, 'Chuck Ebbert', 'linux-kernel'

On Thu, Apr 10, 2003 at 04:06:36PM -0600, you [Andreas Dilger] wrote:
>
>   From what I've read, it sounds like the solution that will be accepted by
> the kernel developers is that kernel messages will continue to be output
> as-is in english, and can be post-processed with a tool to translate it to
> another language.  The tool will grab the format strings from the kernel
> so that it can separate out the constant and variable parts of the message,
> and the format strings will be translated.
> 
> At translation time, _something_ _like_ "sscanf(format_string, ...)" will
> be used to detect the which message is which (probably being speeded up
> with a pattern-matching hash of the constant parts of the message like
> prcs/xdelta does), substituting the english format with the translated
> format, and then substituting the args.

But the sscanf parsing is fragile if not impossible to get right in some
cases. How do you parse the output of printk("file %s on device %s
corrupted", file, devname); if file the file contains spaces and whatever?

Why not make it so that kernel can be configured to output messages as
<format string>,<arg>,<arg>... where the format string is what is usually
passed to *printf. (The actual field separators could be \0 or something.)
Then you can use standard gnu gettext to get the translation in user space
(i18n aware klogd, whatever) and apply the formatting after that.

Actually, the structured message pool could be separate from the normal one,
so that the existing tools don't break. Both the old style and formatted
message pool could be configured on and off based on user needs when
compiling the kernel. 

And the change should be pretty easy and centralized in kernel. This only
adds the run time over head of maintaing two pools iff both are configured
on.

(Not that I need i18n kernel or would ever use one. And I'm fairly sure
no-one gets around to implement it anyway...)


-- v --

v@iki.fi

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
@ 2003-04-10 23:23 Chuck Ebbert
  0 siblings, 0 replies; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-10 23:23 UTC (permalink / raw)
  To: Bernd Petrovitsch, linux-kernel


>>>> "%s: name %p is %d\n", "stringval", 0x4790243, 44
>[...]
>> The real problem I see is that this approach doesn't make it any
>>easier to translate the messages.
>
>If you habe the above, you could use/copy/reuse gettext() since the 
>format string is used a key/hash/unique id for the translation.


 If all you need is the hash of the format string, why not put that
at the end of the log message, i.e.

  <severity>message<hash>

(Note this is the hash of the *format* string, not the message.)

This would be nearly-trivial to do.


--
 Chuck

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 22:13 Chuck Ebbert
@ 2003-04-10 22:33 ` Stephen Hemminger
  0 siblings, 0 replies; 137+ messages in thread
From: Stephen Hemminger @ 2003-04-10 22:33 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: linux-kernel

On Thu, 10 Apr 2003 18:13:06 -0400
Chuck Ebbert <76306.1226@compuserve.com> wrote:

> John Bradford wrote:
> 
> 
> > When are we going to see versioned filesystems in Linux?  That
> > was a standard feature in VMS.
> 
> 
>   Just a trivial change the the VFS, no doubt.
> 

I think it's been tried already:
	http://www.cs.wisc.edu/~param/class/lvl_slides.ppt

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
@ 2003-04-10 22:13 Chuck Ebbert
  2003-04-10 22:33 ` Stephen Hemminger
  0 siblings, 1 reply; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-10 22:13 UTC (permalink / raw)
  To: linux-kernel

John Bradford wrote:


> When are we going to see versioned filesystems in Linux?  That
> was a standard feature in VMS.


  Just a trivial change the the VFS, no doubt.


--
 Chuck
 I am not a number!

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 21:20 Perez-Gonzalez, Inaky
@ 2003-04-10 22:06 ` Andreas Dilger
  2003-04-11  7:38   ` Ville Herva
  0 siblings, 1 reply; 137+ messages in thread
From: Andreas Dilger @ 2003-04-10 22:06 UTC (permalink / raw)
  To: Perez-Gonzalez, Inaky; +Cc: 'Chuck Ebbert', 'linux-kernel'

On Apr 10, 2003  14:20 -0700, Perez-Gonzalez, Inaky wrote:
> > From: Chuck Ebbert [mailto:76306.1226@compuserve.com]
> > >>      How about changing the way printk works, so that instead of
> > >> combining the format string, it just "prints" its args:
> > >>
> > >> printk("%s: name %p is %d\n", name, ptr, val);
> > >>
> > >> results in the following in the kernel buffer:
> > >>
> > >> "%s: name %p is %d\n", "stringval", 0x4790243, 44
> > >
> > > Debugging a non-klogd enabled kernel would be a pain
> > 
> > 
> >  Why?  Shouldn't it be easy to fix dmesg so it unmangles the output?
> 
> s/non-klogd enabled/dmesg/
> 
> Same thing - what I mean is that if you don't have some automatic
> means to recompose the messages, reading the direct output of 
> the console (as sometimes you have to), becomes a mess.

  From what I've read, it sounds like the solution that will be accepted by
the kernel developers is that kernel messages will continue to be output
as-is in english, and can be post-processed with a tool to translate it to
another language.  The tool will grab the format strings from the kernel
so that it can separate out the constant and variable parts of the message,
and the format strings will be translated.

At translation time, _something_ _like_ "sscanf(format_string, ...)" will
be used to detect the which message is which (probably being speeded up
with a pattern-matching hash of the constant parts of the message like
prcs/xdelta does), substituting the english format with the translated
format, and then substituting the args.

This has the benefit that it can be used in klogd/dmesg/ksymoops, or even
as a standalone tool for filtering kernel messages in email or over a
serial console, and you can also get multiple translations instead of
just the one that was output to the screen.

Cheers, Andreas

PS: 2.4.18 has 51217 printks, 2.5.recent has 59728.  Some of them don't need
    to be translated, some of them are hidden inside macros.  In any case,
    there is a lot of actual translation that needs to be done to make this
    practical regardless of what the details are.
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/


^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-english user messages
@ 2003-04-10 21:20 Perez-Gonzalez, Inaky
  2003-04-10 22:06 ` Andreas Dilger
  0 siblings, 1 reply; 137+ messages in thread
From: Perez-Gonzalez, Inaky @ 2003-04-10 21:20 UTC (permalink / raw)
  To: 'Chuck Ebbert', 'linux-kernel'


> From: Chuck Ebbert [mailto:76306.1226@compuserve.com]
>
> >>      How about changing the way printk works, so that instead of
> >> combining the format string, it just "prints" its args:
> >>
> >> printk("%s: name %p is %d\n", name, ptr, val);
> >>
> >> results in the following in the kernel buffer:
> >>
> >> "%s: name %p is %d\n", "stringval", 0x4790243, 44
> >
> > Debugging a non-klogd enabled kernel would be a pain
> 
> 
>  Why?  Shouldn't it be easy to fix dmesg so it unmangles the output?

s/non-klogd enabled/dmesg/

Same thing - what I mean is that if you don't have some automatic
means to recompose the messages, reading the direct output of 
the console (as sometimes you have to), becomes a mess.

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-10 20:54 kernel support for non-english " Chuck Ebbert
@ 2003-04-10 21:08 ` Bernd Petrovitsch
  0 siblings, 0 replies; 137+ messages in thread
From: Bernd Petrovitsch @ 2003-04-10 21:08 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: linux-kernel

Chuck Ebbert <76306.1226@compuserve.com> wrote:
>>>      How about changing the way printk works, so that instead of
>>> combining the format string, it just "prints" its args:
>>> 
>>> printk("%s: name %p is %d\n", name, ptr, val);
>>> 
>>> results in the following in the kernel buffer:
>>> 
>>> "%s: name %p is %d\n", "stringval", 0x4790243, 44
[...]
> The real problem I see is that this approach doesn't make it any
>easier to translate the messages.

If you habe the above, you could use/copy/reuse gettext() since the 
format string is used a key/hash/unique id for the translation.

	Bernd
-- 
Bernd Petrovitsch                              Email : bernd@gams.at
g.a.m.s gmbh                                  Fax : +43 1 205255-900
Prinz-Eugen-Straße 8                    A-1040 Vienna/Austria/Europe
                     LUGA : http://www.luga.at



^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-english user messages
@ 2003-04-10 20:54 Chuck Ebbert
  2003-04-10 21:08 ` Bernd Petrovitsch
  0 siblings, 1 reply; 137+ messages in thread
From: Chuck Ebbert @ 2003-04-10 20:54 UTC (permalink / raw)
  To: Perez-Gonzalez, Inaky, linux-kernel


>>      How about changing the way printk works, so that instead of
>> combining the format string, it just "prints" its args:
>> 
>> printk("%s: name %p is %d\n", name, ptr, val);
>> 
>> results in the following in the kernel buffer:
>> 
>> "%s: name %p is %d\n", "stringval", 0x4790243, 44
>
> Debugging a non-klogd enabled kernel would be a pain


 Why?  Shouldn't it be easy to fix dmesg so it unmangles the output?

 The real problem I see is that this approach doesn't make it any
easier to translate the messages.

  Maybe someone should just try to write a Babelfish-like thing that
takes English kernel-speak and translates it as best it can?  It would
at least be amusing to read the output. :)

--
 Chuck
 I am not a number!

^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-english user messages
  2003-04-10 19:21 Perez-Gonzalez, Inaky
@ 2003-04-10 20:41 ` Robert White
  2003-04-11  9:21   ` kernel support for non-English " Riley Williams
  0 siblings, 1 reply; 137+ messages in thread
From: Robert White @ 2003-04-10 20:41 UTC (permalink / raw)
  To: Perez-Gonzalez, Inaky, 'Ruth Ivimey-Cook', linux-kernel

It is tautologically true that every printk starts with a format string, and
that "really" the kernel has no business "switching languages" on the fly.
That is, like selecting the chipset, the language the kernel should express
it self ought to be selected at compile time.

In essence, the translations have to be done earlier in the process instead
of later.  Having or needing a tool to read the log won't help someone
trying to diagnose a problem where a tool isn't in place and the storage
requirements for after-the-fact to see and use the output become
unreasonable.  (It's just not telnet/shell friendly.)

(being innocent of intent, for a moment, i.e. this isn't a recommendation at
this time, just a though experiment...)

Consider a tool that scans any source file and collects up the literal
strings of every printk encountered and tosses them into a static array,
"CHAR_TYPE * KernelMessage[] = { "whatever", "whatever"...};" then replaces
"printk("whatever",...);" with "printk(KernelMessage[0],...);"

subsequent runs of this theoretical tool will take any new prink(s) found
and add them to the list.

For completeness, any KernelMessage subscripts never used (cause the printk
was removed) would get burped out of the sequence at re-expression time.

Once that was done to any/every module, source, etc. the person wishing
translate a fragment needs only go into that file, and a branching define,
and translate the array of messages into the language of their intent.

Now the kernel "naturally" speaks the target language.

The Flaws however:

1) Needs this magic tool.
2) Needs each developer to support the tool.
3) Removes the comment-like value of the messages in the text because you
would have to cross-reference the KernelMessage subscript during development
to see what the program would try to output.
4) Each language would need a maintainer.  (i.e. want a French and a Spanish
kernel you need the French language manager and a Spanish language manager)
5) It's not patch friendly.  (Two people separately add a prink and run the
tool, now two different texts are intended for say KernelMessage[140] in
exit.c) which means un-official patches need to be not-language-enabled
which in turn means that the tool needs to be kept under guard to prevent
misuse etc.
6) Header Problems.  (printk's in headers would force each such header to
have it's own dedicated non-static  message array in a separate source file.

(and so on)

=====

Given that the above is actually the "logically most direct" solution set,
and every step you take further away from modifying the source and compiling
up a single-desired-target-language kernel induces non-trivial loss of
information/clarity at substantial analysis-time expense, I suspect that the
whole problem of "really" making the kernel multi-lingual is NP Complete.

=====

Now consider that any "regular expression or whatever" post processing that
someone might want to put into klogd is a fixed cost expense at runtime, but
in theory most runtime events are successes, one can conclude that that cost
really should only be paid only when someone is actually looking at the
messages.

That naturally infers that the translation shouldn't happen in klogd, but
instead much later at evaluation time.

If you push the evaluation-time (human reading etc) hypothesis to its
conclusion, and fold in the need to manage the per-language effort
coherently, you are led almost inexorably to an external "kernel message
translator" project.

This project would have a generic base and a per-language specialization.

The translator would have two phases, a harvester phase that would literally
collect up all the likely output strings from the entire kernel tree and
drop them into a data file.  Some sort of hashing should be done to find new
and old strings so as to preserve prior runs etc.  The file should also be
able to reasonably find/define the substitution engine for any given message
because it will have the in-place substitution markers (e.g. "%s");

The expressor would take that file and a companion file that listed target
translations, and then do the translation.  The expressor would only be run
when a person was interested in the output.  It would, of course, be fed the
contents of /var/log/messages or wherever the klogd is sending things.  For
people who MUST HAVE the translations real-time, klogd would/could be wired
up to pipe its output through the translator when necessary.

Untranslated lines would pass through unchanged.

A optional third part would be an editor that brought up the two files (the
source hash and the current translation for a language, and let someone who
could translate the strings, enter the well formed desired output with value
markers from the substitution engine.  (e.g. "foo:<value1>" would set
$1=value1 in the extraction engine and then substitute it into the constant
target "blah blah $1 blah", where blah is a real useful text in the target
language. 8-)

In short, The task really requires a heinous post processor, a language
maintainer per target language, and such a project should *NOT* be part of
the kernel tree or it will be trashed over time.

Rob.

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Perez-Gonzalez,
Inaky
Sent: Thursday, April 10, 2003 12:22 PM
To: 'Ruth Ivimey-Cook'; 'linux-kernel@vger.kernel.org'
Subject: RE: kernel support for non-english user messages




> From: Ruth Ivimey-Cook [mailto:Ruth.Ivimey-Cook@ivimey.org]
>
> >This is _not_ like any i18n support.  The problem is that normal
>
> Agreed. How about changing the way printk works, so that instead of
> combining the format string, it just "prints" its args:
>
> printk("%s: name %p is %d\n", name, ptr, val);
>
> results in the following in the kernel buffer:
>
> "%s: name %p is %d\n", "stringval", 0x4790243, 44

Debugging a non-klogd enabled kernel would be a pain - alas, having some
preprocessing tool, this can be done without that modification. If you
know the format string (from the sources), given a printed message, a
regexp could extract the parts that need translation.

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-english user messages
@ 2003-04-10 19:21 Perez-Gonzalez, Inaky
  2003-04-10 20:41 ` Robert White
  0 siblings, 1 reply; 137+ messages in thread
From: Perez-Gonzalez, Inaky @ 2003-04-10 19:21 UTC (permalink / raw)
  To: 'Ruth Ivimey-Cook', 'linux-kernel@vger.kernel.org'



> From: Ruth Ivimey-Cook [mailto:Ruth.Ivimey-Cook@ivimey.org]
>
> >This is _not_ like any i18n support.  The problem is that normal
> 
> Agreed. How about changing the way printk works, so that instead of
> combining the format string, it just "prints" its args:
> 
> printk("%s: name %p is %d\n", name, ptr, val);
> 
> results in the following in the kernel buffer:
> 
> "%s: name %p is %d\n", "stringval", 0x4790243, 44

Debugging a non-klogd enabled kernel would be a pain - alas, having some
preprocessing tool, this can be done without that modification. If you 
know the format string (from the sources), given a printed message, a 
regexp could extract the parts that need translation.

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)

^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
  2003-04-09 23:31 Jim Keniston[UNIX]
@ 2003-04-10 19:01 ` Alan Cox
  2003-04-11  9:21   ` kernel support for non-English " Riley Williams
  0 siblings, 1 reply; 137+ messages in thread
From: Alan Cox @ 2003-04-10 19:01 UTC (permalink / raw)
  To: Jim Keniston[UNIX]; +Cc: Linux Kernel Mailing List

On Thu, 2003-04-10 at 00:31, Jim Keniston[UNIX] wrote:
> Kernel messages need to be logged in English.  By application of message
> catalogs or similar techniques, they can also be made available in other
> languages.  Translation to other languages should be done when the log
> is viewed.

Absolutely agreed. The only case you might want to argue otherwise is
panic and very early boot messages. and even then it is questionable.

> 	printk(KERN_INFO "link up, %d Mbps, %s-duplex\n", speed, duplex);
> you log the format string and the values of speed and duplex as separate
> attributes in the event log.  If/when you compute a hash, it's on the
> format string (and possibly on the function name and/or source-file
> name, to provide more context).

One of the problems is extracting the format string and other data. 

Making the log hold
<6>%s: carrier dropped and smashed on the floor[U001]eth0

is in itself not hard and a big step forward.

> - If we use 32-bit hash codes, there's a real chance of different
> messages

There are less than 65536 files each of which is less than 65536 lines
long, so it seems that a properly chosen automated index ought to be
collision free ?



^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
@ 2003-04-10 10:47 Ruth Ivimey-Cook
  0 siblings, 0 replies; 137+ messages in thread
From: Ruth Ivimey-Cook @ 2003-04-10 10:47 UTC (permalink / raw)
  To: linux-kernel

At 23:55 09/04/2003, you wrote:
> > "My suggestion would be to add the required i18n support to klogd, so
> > that kernel messages are translated as they are removed from dmesg into
> > syslog. Then, like any i18n support,
>
>This is _not_ like any i18n support.  The problem is that normal

Agreed. How about changing the way printk works, so that instead of 
combining the format string, it just "prints" its args:

printk("%s: name %p is %d\n", name, ptr, val);

results in the following in the kernel buffer:

"%s: name %p is %d\n", "stringval", 0x4790243, 44


Then run a process to either push them together again (native mode) or do 
the getmsg() thing for i18n mode?

Only problem I can see is early-boot, where the normal demons can't be 
running. Could we have a  kernel-thread that can be run ASAP and does the 
native-mode thing, that can be killed if userspace runs an i18n demon?

HTH,

Ruth  


^ permalink raw reply	[flat|nested] 137+ messages in thread

* Re: kernel support for non-english user messages
@ 2003-04-09 23:31 Jim Keniston[UNIX]
  2003-04-10 19:01 ` Alan Cox
  0 siblings, 1 reply; 137+ messages in thread
From: Jim Keniston[UNIX] @ 2003-04-09 23:31 UTC (permalink / raw)
  To: linux-kernel

I'm one of those IBM guys who has been working on ideas for enhanced
error/event logging in Linux.  As part of this work, we've developed
ideas for I18N of event-log messages.  Here are some observations:

Most developers are comfortable with printk.  Whatever approach you
take, the closer you stay to printk in the programmatic interface, the
more likely you are to gain acceptance.

Kernel messages need to be logged in English.  By application of message
catalogs or similar techniques, they can also be made available in other
languages.  Translation to other languages should be done when the log
is viewed.

If you're serious about I18N, you must keep a message's format string 
distinct from the arg list.  Your event-log viewer combines them all for
you, using the desired language.  For example, given the message
	printk(KERN_INFO "link up, %d Mbps, %s-duplex\n", speed, duplex);
you log the format string and the values of speed and duplex as separate
attributes in the event log.  If/when you compute a hash, it's on the
format string (and possibly on the function name and/or source-file
name, to provide more context).

Note that if you're particularly brave and/or stingy, you don't even
have
to log the format string, just the hash.  The event-log viewer can fetch
the format string given the hash.

As the above suggests, a structured event log (see, for example,
evlog.sourceforge.net) lends itself more readily to manipulation and
analysis than does a simple text file.

We've come up with a couple of ways of generating message catalogs
automatically.  The method we prefer captures information about each
printk* at compile time, and stores it in the .log section of the .o
file.  A post-processor then reads all the .o files and generates a sort
of catalog entry for each printk call.  The .log sections are stripped
out when the bzImage is created.  [*This technique requires some macro
fussing.  For reasons I won't go into, the macro is NOT called "printk",
so this feature doesn't come for free.]

There are tens of thousands of printk calls in Linux.  This has several
implications:

- Inertia is a major factor.

- If we use 32-bit hash codes, there's a real chance of different
messages
yielding the same hash code.  We take the approach that each subsystem
(e.g., each device driver) gets its own facility code (i.e., not KERN
for everybody).  If you key on hash code AND facility, the chance of
collisions is very small.

- Although I believe it's worthwhile to categorize messages and tag them
accordingly -- e.g., "hardware failure: <description of problem>" or
"configuration note: <whatever>" -- most of the existing printk messages
contain very context-specific info, and couldn't be entirely replaced
with standard messages without loss of useful info.

Jim Keniston
IBM Linux Technology Center

^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-english user messages
@ 2003-04-09 19:25 Perez-Gonzalez, Inaky
  0 siblings, 0 replies; 137+ messages in thread
From: Perez-Gonzalez, Inaky @ 2003-04-09 19:25 UTC (permalink / raw)
  To: 'oliver@neukum.name', 'Matti Aarnio',
	'Frank Davis'
  Cc: 'linux-kernel@vger.kernel.org'


> From: Oliver Neukum 

> If we do this, why not go the whole way?
> Could we compute a hash value for every message that's not KERN_CRIT,
> use it to create a table of messages and hashes and replace the messages
> in the kernel image with the hash values leaving expansion to klogd?

What about argument expansion? You are killing it

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)


^ permalink raw reply	[flat|nested] 137+ messages in thread

* RE: kernel support for non-english user messages
@ 2003-04-09 19:01 Perez-Gonzalez, Inaky
  0 siblings, 0 replies; 137+ messages in thread
From: Perez-Gonzalez, Inaky @ 2003-04-09 19:01 UTC (permalink / raw)
  To: 'fdavis@si.rr.com', 'linux-kernel@vger.kernel.org'


> I wish to suggest a possible 2.6 or 2.7 feature (too late for 2.4.x and
> 2.5.x, I believe) that I believe would be helpful. Currently, printk
> messages are all in english, and I was wondering if printk could be
> modified to print out user messages that are in the default language of
> the machine. For example,

A classic: http://www.tux.org/lkml/#s9-16

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)

^ permalink raw reply	[flat|nested] 137+ messages in thread

end of thread, other threads:[~2003-04-26  6:41 UTC | newest]

Thread overview: 137+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-09  5:02 kernel support for non-english user messages Frank Davis
2003-04-09  5:29 ` Oliver Neukum
2003-04-09  5:50   ` Frank Davis
2003-04-09  9:37     ` Bernd Petrovitsch
2003-04-09 11:04   ` Alan Cox
2003-04-09  5:53 ` Andreas Dilger
2003-04-09  8:08 ` Matti Aarnio
2003-04-09  9:33   ` Oliver Neukum
2003-04-09 10:24     ` Matti Aarnio
2003-04-09 22:07   ` Werner Almesberger
2003-04-09 22:41     ` Frank Davis
2003-04-09 22:55       ` Ulrich Drepper
2003-04-09 23:53         ` Johannes Ruscheinski
2003-04-10  1:43       ` Richard B. Johnson
2003-04-10 18:57         ` Alan Cox
2003-04-10 20:13           ` Trond Myklebust
2003-04-10 19:42             ` Alan Cox
2003-04-11  0:48               ` Christer Weinigel
2003-04-11 15:56                 ` Daniel Stekloff
2003-04-10 20:53             ` Richard B. Johnson
2003-04-10 23:05               ` Jon Portnoy
2003-04-11  5:39                 ` DevilKin
2003-04-11  5:49                   ` Arnaldo Carvalho de Melo
2003-04-11  6:17                     ` DevilKin
2003-04-11 17:51                     ` Randy.Dunlap
2003-04-11 11:57               ` Helge Hafting
2003-04-11 17:55                 ` David Lang
2003-04-10 20:36           ` John Bradford
2003-04-10 22:20             ` Shaya Potter
2003-04-11  4:19               ` Valdis.Kletnieks
2003-04-11  4:23                 ` Shaya Potter
2003-04-11  8:40                   ` Henning P. Schmiedehausen
2003-04-11  9:09                 ` John Bradford
2003-04-11 10:59                   ` Valdis.Kletnieks
2003-04-11 11:11                     ` John Bradford
2003-04-11 11:40                 ` Helge Hafting
2003-04-24 23:25             ` versioned filesystems in linux (was Re: kernel support for non-english user messages) Stewart Smith
2003-04-25  7:14               ` John Bradford
2003-04-25 15:20               ` Matthew Sell
2003-04-25 15:45                 ` Richard B. Johnson
2003-04-25 16:18                   ` versioned filesystems in linux (was Re: kernel support for John Bradford
2003-04-25 17:06                     ` Richard B. Johnson
2003-04-25 17:48                       ` Valdis.Kletnieks
2003-04-25 19:38                         ` H. Peter Anvin
2003-04-25 21:21                           ` 9-track tape drive (Was: Re: versioned filesystems in linux) John Bradford
2003-04-25 21:22                             ` H. Peter Anvin
2003-04-25 21:31                               ` Mike Dresser
2003-04-26  6:32                                 ` H. Peter Anvin
2003-04-26  6:57                                   ` John Bradford
2003-04-25 18:13                       ` versioned filesystems in linux (was Re: kernel support for John Bradford
2003-04-25 18:34                         ` Richard B. Johnson
2003-04-10  8:19       ` kernel support for non-english user messages Oliver Neukum
2003-04-09 13:11 ` Giuliano Pochini
2003-04-10  3:08 ` Linus Torvalds
2003-04-10  9:05   ` kernel support for non-English " Riley Williams
2003-04-10 17:35     ` Linus Torvalds
2003-04-10 18:32       ` John Bradford
2003-04-12  2:55       ` Chris Wedgwood
2003-04-09 19:01 kernel support for non-english " Perez-Gonzalez, Inaky
2003-04-09 19:25 Perez-Gonzalez, Inaky
2003-04-09 23:31 Jim Keniston[UNIX]
2003-04-10 19:01 ` Alan Cox
2003-04-11  9:21   ` kernel support for non-English " Riley Williams
2003-04-11 12:16     ` Alan Cox
2003-04-11 13:39       ` John Bradford
2003-04-11 13:11         ` Alan Cox
2003-04-11 14:48           ` John Bradford
2003-04-10 10:47 kernel support for non-english " Ruth Ivimey-Cook
2003-04-10 19:21 Perez-Gonzalez, Inaky
2003-04-10 20:41 ` Robert White
2003-04-11  9:21   ` kernel support for non-English " Riley Williams
2003-04-11 20:49     ` Robert White
2003-04-11 22:53       ` Riley Williams
2003-04-15  3:44         ` Robert White
2003-04-15 11:08           ` Alan Cox
2003-04-15 11:08           ` Alan Cox
2003-04-15 14:07           ` Timothy Miller
2003-04-11 21:04     ` Ruth Ivimey-Cook
2003-04-11 21:31       ` Daniel Stekloff
2003-04-10 20:54 kernel support for non-english " Chuck Ebbert
2003-04-10 21:08 ` Bernd Petrovitsch
2003-04-10 21:20 Perez-Gonzalez, Inaky
2003-04-10 22:06 ` Andreas Dilger
2003-04-11  7:38   ` Ville Herva
2003-04-10 22:13 Chuck Ebbert
2003-04-10 22:33 ` Stephen Hemminger
2003-04-10 23:23 Chuck Ebbert
2003-04-11 10:10 Chuck Ebbert
     [not found] <20030409051006$1ecf@gated-at.bofh.it>
     [not found] ` <20030409081011$5257@gated-at.bofh.it>
     [not found]   ` <20030409221017$6c98@gated-at.bofh.it>
     [not found]     ` <20030409225009$2558@gated-at.bofh.it>
     [not found]       ` <20030410014009$78fb@gated-at.bofh.it>
     [not found]         ` <20030410200019$3e8f@gated-at.bofh.it>
     [not found]           ` <20030410202016$7d48@gated-at.bofh.it>
2003-04-11 11:29             ` Tim Connors
2003-04-11 13:17 kernel support for non-English " Chuck Ebbert
2003-04-11 13:40 ` John Bradford
2003-04-16  1:59   ` Gerrit Huizenga
2003-04-16 14:28     ` Timothy Miller
2003-04-16 14:37       ` Alan Cox
2003-04-16 16:20         ` Timothy Miller
2003-04-16 17:04       ` Bruce Harada
2003-04-16 18:34         ` Timothy Miller
2003-04-16 18:37           ` Bruce Harada
2003-04-11 14:37 ` Richard B. Johnson
2003-04-11 16:00 ` Linus Torvalds
2003-04-12  8:22 ` Kai Henningsen
2003-04-12 11:08   ` John Bradford
2003-04-11 14:52 Paolo Ciarrocchi
2003-04-11 16:57 Chuck Ebbert
2003-04-11 17:38 ` Richard B. Johnson
2003-04-11 18:10 ` Matti Aarnio
2003-04-11 20:02 kernel support for non-english " Perez-Gonzalez, Inaky
     [not found] <A46BBDB345A7D5118EC90002A5072C780BEBA7DD@orsmsx116.jf.inte l.com>
2003-04-11 20:55 ` Ruth Ivimey-Cook
2003-04-11 22:21 kernel support for non-English " Chuck Ebbert
2003-04-11 22:53 ` Martin J. Bligh
2003-04-12  7:55   ` John Bradford
2003-04-12  7:48 ` John Bradford
2003-04-14 11:40 ` Denis Vlasenko
2003-04-14 12:55   ` John Bradford
2003-04-14 17:29     ` Linus Torvalds
2003-04-14 18:15       ` John Bradford
2003-04-14 23:04       ` Felipe Alfaro Solana
2003-04-15 13:21       ` Alex Combas
2003-04-15 18:02       ` Eric Altendorf
2003-04-17 13:46         ` Alan Cox
2003-04-17 15:07         ` Randolph Bentson
2003-04-17 18:49           ` Eric Altendorf
2003-04-14 13:18   ` Sean Neakums
2003-04-14 14:23   ` Valdis.Kletnieks
2003-04-16  5:03     ` Denis Vlasenko
2003-04-11 23:36 Jim Keniston[UNIX]
2003-04-11 23:38 Chuck Ebbert
2003-04-12  9:52 Chuck Ebbert
2003-04-12 15:20 Chuck Ebbert
2003-04-12 15:34 ` Alan Cox
2003-04-12 17:22   ` Robert P. J. Day
2003-04-13  3:59     ` Martin J. Bligh
2003-04-13  6:21   ` John Bradford
2003-04-12 16:47 Chuck Ebbert
2003-04-12 20:31 Chuck Ebbert
2003-04-14  9:07 ` Denis Vlasenko
2003-04-14 21:27 Chuck Ebbert

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).