linux-kernel - Re: [GIT PULL/RESEND] kernel message catalog patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 27 Oct 2008 09:10:56 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org
Subject: Re: [GIT PULL/RESEND] kernel message catalog patches

On Mon, 27 Oct 2008, Alan Cox wrote:
>
> > And as for the actual explanations: either they need to be totally outside 
> > the kernel (in a project of their own), or they'd need to be "kernel-doc" 
> > style things that are _in_ the source code. Not in Documentation/. Not 
> > separate from the printk() that they are associated with.
> 
> You really don't want 32 languages in mixed left/right rendering with
> multiple fonts in your kernel source. At least not with most editing and
> viewing tools....

I do agree. Another issue is that quite often the actual line to be 
printed is likely fairly short, and often in an error path (so it's 
indented and in an inconvenient place), but the explanation - even for a 
_single_ language - may well be pretty involved and long.

Which is why I think for something like this, it really needs to be 
entirely outside. Because putting it inside the kernel simply isn't going 
to result in anything really useful. Either it can be close to the message 
and be updated reasonably (never mind that if we really do support 
multiple languages, that's not going to happen anyway, even if it's 
close), or it's going to be somewhere else and not be updated when changes 
happen - and then it migth as well be a separate project.

The 'separate project' is especially appropriate since any parsing won't 
be done by the kernel anyway, but by some ksyslog thing.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/