kernel support for non-english user messages

kernel support for non-english user messages

[Frank Davis]

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

Re: kernel support for non-english user messages

[Oliver Neukum]

> 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

Re: kernel support for non-english user messages

[Frank Davis]

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
> 
> 

Re: kernel support for non-english user messages

[Bernd Petrovitsch]

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

Re: kernel support for non-english user messages

[Alan Cox]

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

Re: kernel support for non-english user messages

[Andreas Dilger]

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/

Re: kernel support for non-english user messages

[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.

...
> 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

Re: kernel support for non-english user messages

[Oliver Neukum]

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

Re: kernel support for non-english user messages

[Matti Aarnio]

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

Re: kernel support for non-english user messages

[Werner Almesberger]

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/____________________________________________/

Re: kernel support for non-english user messages

[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.

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
> 

Re: kernel support for non-english user messages

[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-----

Re: kernel support for non-english user messages

[Johannes Ruscheinski]

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

Re: kernel support for non-english user messages

[Richard B. Johnson]

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.

Re: kernel support for non-english user messages

[Alan Cox]

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

Re: kernel support for non-english user messages

[Trond Myklebust]

>>>>> " " == 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

Re: kernel support for non-english user messages

[Alan Cox]

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)

Re: kernel support for non-english user messages

[Christer Weinigel]

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

Re: kernel support for non-english user messages

[Daniel Stekloff]

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

Re: kernel support for non-english user messages

[Richard B. Johnson]

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.

Re: kernel support for non-english user messages

[Jon Portnoy]

[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.

Re: kernel support for non-english user messages

[DevilKin]

-----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-----

Re: kernel support for non-english user messages

[Arnaldo Carvalho de Melo]

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

Re: kernel support for non-english user messages

[DevilKin]

-----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-----

Re: kernel support for non-english user messages

[Randy.Dunlap]

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."]

Re: kernel support for non-english user messages

[Helge Hafting]

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

Re: kernel support for non-english user messages

[David Lang]

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

Re: kernel support for non-english user messages

[John Bradford]

> 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.

Re: kernel support for non-english user messages

[Shaya Potter]

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.

Re: kernel support for non-english user messages

[Valdis.Kletnieks]

[-- 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 --]

Re: kernel support for non-english user messages

[Shaya Potter]

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.

Re: kernel support for non-english user messages

[Henning P. Schmiedehausen]

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

Re: kernel support for non-english user messages

[John Bradford]

> 
> --==_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.

Re: kernel support for non-english user messages

[Valdis.Kletnieks]

[-- 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 --]

Re: kernel support for non-english user messages

[John Bradford]

> > 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.

Re: kernel support for non-english user messages

[Helge Hafting]

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

versioned filesystems in linux (was Re: kernel support for non-english user messages)

[Stewart Smith]

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

Re: versioned filesystems in linux (was Re: kernel support for non-english user messages)

[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.

Re: versioned filesystems in linux (was Re: kernel support for non-english user messages)

[Matthew Sell]

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

Re: versioned filesystems in linux (was Re: kernel support for non-english user messages)

[Richard B. Johnson]

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.

Re: versioned filesystems in linux (was Re: kernel support for

[John Bradford]

> 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.

Re: versioned filesystems in linux (was Re: kernel support for

[Richard B. Johnson]

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.

Re: versioned filesystems in linux (was Re: kernel support for

[Valdis.Kletnieks]

[-- 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 --]

Re: versioned filesystems in linux (was Re: kernel support for

[H. Peter Anvin]

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

9-track tape drive (Was: Re: versioned filesystems in linux)

[John Bradford]

> > 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.

Re: 9-track tape drive (Was: Re: versioned filesystems in linux)

[H. Peter Anvin]

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

Re: 9-track tape drive (Was: Re: versioned filesystems in linux)

[Mike Dresser]

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

Re: 9-track tape drive (Was: Re: versioned filesystems in linux)

[H. Peter Anvin]

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

Re: 9-track tape drive (Was: Re: versioned filesystems in linux)

[John Bradford]

> > > 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.

Re: versioned filesystems in linux (was Re: kernel support for

[John Bradford]

> > 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.

Re: versioned filesystems in linux (was Re: kernel support for

[Richard B. Johnson]

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.

Re: kernel support for non-english user messages

[Oliver Neukum]

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

RE: kernel support for non-english user messages

[Giuliano Pochini]

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.

Re: kernel support for non-english user messages

[Linus Torvalds]

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

Re: kernel support for non-English user messages

[Riley Williams]

[-- 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])

Re: kernel support for non-English user messages

[Linus Torvalds]

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

Re: kernel support for non-English user messages

[John Bradford]

> 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.

Re: kernel support for non-English user messages

[Chris Wedgwood]

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