lkml.org 
[lkml]   [1997]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel-Messages translation


On Fri, 20 Jun 1997, Rafal Maszkowski wrote:

[...]
> setting up some ways of message->action translation in their minds. It
>
[...]
> kernel module. It can't be a user space program because it won't work
> during the kernel startup.
[...]

Nonuserspace translations of boot messages for such users (ones who dont
know much about linux) is of little importance. If the error message
is fatal such that a userspace daemon could not translate the message for
them then the course of action would be the same regardless of the actual
message: "Call the Linux Guru"..

I do however think a change would be good.. I would like to see messages
replaced with things like

"KERNEL(L).SUBSYS.SUBERROR.SPECIFICERROR!MOREINFO"
KERNEL would be mandatory.. If there are only two field then it is a raw
kernel problem.. If there are 3 then it is
KERNEL.SUBSYS.SPECIFICERROR!MOREINFO.. You get the point.. L would be a
severity level (I'm not sure what the current numbering system is.. but
we'd use that..)

i.e.
KERNEL(2).EXT2FS.BADINODE!"12345"

Thern there would be a database of translations between that stuff and
sane messages.. The kernel would include english and there would be a
compile time option of putting a "Lite" english decoder in the kernel..
All other languages can be done with a userspace solution.. And
translation could be turned off completely.. (I'd be quite happy with the
terse responce).. This solution (the hierarchial method) would allow some
great flexibility for translations.. I.e. If the translation were poor it
could provide a general responce: "An untranslated EXT2FS error 'BADINODE'
has occured..."

The english of above would be "Kernel: Ext2fs has detected inode 12345 is
corrupt"... Both the kernel and the translated (if translation is on)
would be printed and/or logged..

Errors like 'KERNEL(3).VFS.PARTICORRUPT!"/dev/hda"' which might occure
before the system could start a userspace translator are not likely to be
solved by a person who couldn't figure out what PARTICORRUPT!"/dev/hda"
ment.. :)

Keeping the verbose messages out of the kernel could make it smaller.. And
if newprintk() could be implmented to see what subsystem it was being
called from it could reduce kernel size.. I would go further to say that
the SPECIFICERROR should be UNIQUE throught the kernel.. Or at least
always have the same meaning.. i.e. (badinode could be in ext and ext2 but
it would MEAN the same thing just in a differnt place..).. More info
should be considerd a string unless the software knows better..

Anyone like the idea? I would appriciate feedback..



\
 
 \ /
  Last update: 2005-03-22 13:39    [W:1.847 / U:1.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site