kernel support for non-english user messages

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

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

Regards
Oliver

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

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/

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

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.

...

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.

/Matti Aarnio

Am Mittwoch, 9. April 2003 10:08 schrieb Matti Aarnio:

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

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

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 : [email protected]
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

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.

/Matti Aarnio

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

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

Bye.

... 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         [email protected] /
/_http://www.almesberger.net/____________________________________________/

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

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

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

Also sprach Ulrich Drepper:

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

[SNIPPED...]

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.

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

Am Donnerstag, 10. April 2003 00:41 schrieb Frank Davis:

This is a nightmare to keep current.

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

Hi Linus.

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

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

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

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.

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

> 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

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

John.

The AST stuff was a bit buggy yes

Give me the clustering support 8)

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.

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.

[CC list trimmed, it was getting ridiculous]

[snip]

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.

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 <[email protected]>  http://www.weinigel.se

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.

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.

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

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

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

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

Em Fri, Apr 11, 2003 at 07:39:35AM +0200, DevilKin escreveu:

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

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

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

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
[email protected]        +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

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

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

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.

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.

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.

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

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.

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.

Sure -which is why this isn't so useful.

Simple solution - duplicate at open() but remove on close() if unchanged.

If you want this, you want a copy-on-write fs. Of course it needs a different fsck.

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.

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.

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.

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

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.

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.

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.

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

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

On Fri, 11 Apr 2003 02:49:32 -0300 Arnaldo Carvalho de Melo <[email protected]> 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."]

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

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

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
[email protected]
Ph: +61 4 3884 4332
ICQ: 6734154

I'm certainly interested in it.

John.

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

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.

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.

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.

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.

Followup to:  <[email protected]>
By author:    [email protected]
In newsgroup: linux.dev.kernel

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

<[email protected]> at work, <[email protected]> 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

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.

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

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

Followup to:  <Pine.LNX.4.33.0304251729490.18442-100000@router.windsormachine.com>
By author:    Mike Dresser <[email protected]>
In newsgroup: linux.dev.kernel

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

-hpa

<[email protected]> at work, <[email protected]> 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

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.