Re: New Feature Idea: Configurable text(msgs)

Captain Napalm (spc@armigeron.com)
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