Messages in this thread | | | Date | Fri, 11 Jun 1999 18:48:40 +0100 (GMT) | From | Riley Williams <> | Subject | Re: Profanity in the Linux Kernel?!?!? |
| |
Hi there.
>>> 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/
| |