>>> Aren't there translations for it, anyway? I mean, it should be
>>> that hard to have language strings of some sort and be able to
>>> use it. Even without it, most English language descriptions may
>>> not have much weight to one who doesn't know English very
>>> well... I think that it's a loss that could be accepted.
>> Personally, I'd prefer to see Linux move over to having any
>> error call a separate module to generate the actual error
>> message, and leave that module to sort out the precice wording
>> thereof. That way, it could be
> Why litter the kernel with messages? Why not just add error
> interpretation to some external daemon.
When I said "module" in the above, it was specifically because the
discussion as to whether the said module is physically part of the
kernel or a userland daemon is unimportant. The important part, at
least IMHO, is that the messages need to be separated from the kernel
itself, and this separation needs to be done in a way that both allows
the messages to be internationalised, and also allows an error report
quoting an error message in one language to be easily understood by
somebody who is less than fluent in the quoted language.
> sysklogd is an excellent place to do that. It would simply
> parse all kerenel messages looking for, say
> "kernel: kerror 00 at 0x0000:0x0000"
> then look it up in some error database and output the translated
> message - and even localized one if you will. Less kernel space,
> more convenience for users, and no more such longish discussions
> as this one. I would gladly code it, if there was consent it's a
> good approach.
That's essentially what I proposed the best part of a year ago, and
the voting was pretty much 97% against, 3% in favour...
>> However, when I proposed such a system some months back, and
>> offered to do the necessary, it was turned down by all
>> concerned, apparently on the basis of the loss of performancee
>> that such a system was claimed to inevitably suffer from.
> If put in the kernel, yes, but in the userland?
Even in the kernel, no performance loss need occur if it's done
correctly, and as far as reporting errors is concerned, I have to
regard it as one area where quality is far more important than
quantity - a misleading or ambiguous error message is worse than no
error message at all in my experience.
The main objection to the idea of moving the translation entirely into
userland is concerned with the "fatal kernel oops", where the use of
any userland code is claimed to risk corruption of the file system.
My personal view on that point is that I can see nothing wrong with
the idea of splitting into two, with code to deal specifically with
suchlike messages included in the kernel, and code to deal with all
other messages in a userland daemon such as klogd or syslogd.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/