Messages in this thread | | | From | Captain Napalm <> | Subject | Re: New Feature Idea: Configurable text(msgs) | Date | Tue, 17 Mar 1998 20:10:04 -0500 (EST) |
| |
It was thus said that the Great Richard B. Johnson once stated: > > On Tue, 17 Mar 1998, Paul Koning wrote: > > > This has been dealt with before... > > > > VMS and OS/360 both had a message prefix (a fixed code) plus the > > message string (a potentially changed human-friendly string. > > Translating would affect the latter but not the former.
[ ... ]
> Yes but... The "kernel-f-oops" wasn't in the kernel. Although some > poorly-written command procedures, including VMSINSTALL.COM, put > these strings in the text. These messages were generated by > SYS$LIBRARY:SYSMSG.EXE and were able to be changed by defining a > new logical name. The actual message was a coded longword.
[ ... ]
> The problem is that developers want to use "free-form" text on > most Unixes including Linux. `grep` through the sources for printk(s) > and you will see. With all these actual strings present in the kernel, > Linus decided several years ago, that all messages will be in English > because most everyone who develops or tests kernel code knows > some English.
It may be too late to fix this for Linux (just too much code) but I know that in some recent projects I've developed an error reporting mechanism that works similarly to VMS. The actual error string is coded in a certain format that can be translated to a human readable error message.
If this is done for Linux, I could see something like:
S:s:N:e
Where S is the system or subsystem (KERNEL, DEVICE, MODULE, etc), s is a subsystem (or subsubsystem) (maybe for DEVICE the major:minor codes, etc), N is a location or place marker (for the project I'm working on, each function is numbered) and e is the actual error. I'm also able to include extra information (using a format string) along with the error. So, for example, the following error from exec_domain.c (2.0.32):
printk(KERN_ERR "No execution domain for personality 0x%02lx\n",pers);
would probably end up like:
logerr(KERNEL,EXEC,__LINE__,ENODOMAIN,"x",pers);
(for example). The output would probably look like:
KERNEL:EXEC:00066:00234:0x34
Ugly yes, but it would be possible to feed through a user space program for translation (I probably wouldn't use __LINE__, but associate a number for each function). It's compact and unambiguous and will probably never be adapted for Linux 8-)
-spc (Remembers the last time this came up)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |