* Riley Williams said:
> > Why litter the kernel with messages? Why not just add error
> > interpretation to some external daemon.
>=20
> 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
Hmm... I can see at least one aspect in which it may be of some importance
where the said module is put - it's the translation issue. It's easier to
maintain the various translations of the error messages when they're kept
outside of the kernel, actually I think that maintaining them in the kernel
would be really bad idea, if possible at all. And i18n is quite an important
issue.
> 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.
I agree. Every error message sent to the system logs should contain both the
prefix of some kind uniquely identifying the error and also a translation.
For the bug reports sent to the kernel maintainers, the log should be piped
through some filter and the output should always be in English. It's easy to
do, I think.
> > 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.
>=20
> That's essentially what I proposed the best part of a year ago, and
> the voting was pretty much 97% against, 3% in favour...
Well, I'm sorry for reinventing the wheel, then :)) - I just don't remember
the post :(((.
> > If put in the kernel, yes, but in the userland?
>=20
> 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
Hmm... yes. If the error handling package was a loadable module, no
performance penalty would take place.
> 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.
I fully agree with you - spent too much time trying to decipher some "user
friendly" Winblows error codes...
> 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.
Those fatal ones should be stuck to the core kernel code, always printed in
English and, if klogd (or any other "interpreter" of kernel errors) still
works, translated anyway.
> 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.
The only problem I can see is the developers - they would have to get used
to putting error messages in some standard place, not directly in the code -
unless some pre-compilation magic is employed and all messages replaced with
some codes or calls of appriopriate type before compiling the kernel.
marek
--yQbNiKLmgenwUfTN
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
iQCVAwUBN2GZQp1EuNB7BOoNAQExGAP9EL+39oqbAOLIlS4eSc4gYGN2U695J2gk
lHgAlR9I7DenlNcdWcOdQ4zZJ0a+GMq2NfasxSZj0BEGDN1KEuXuFP88v8QWlrY/
6La93n6Oc0ZXo+YBYldJ9QN+OdyRkacmYn3gwp1vJR1gtTDm13WzDWedR0+Xh/2x
XwmabIbb1gA=
=GM4R
-----END PGP SIGNATURE-----
--yQbNiKLmgenwUfTN--
-
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/