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]

Message-ID: <alpine.LFD.2.00.0810270750100.3386@nehalem.linux-foundation.org>
Date:	Mon, 27 Oct 2008 08:05:29 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Martin Schwidefsky <schwidefsky@...ibm.com>
cc:	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, Martin Schwidefsky wrote:
> 
> Ok, understood. Not that the reaction surprises me, seems like nobody
> likes documentation (including me).

It's that I don't like out-of-line documentation. It's a damn pain to 
maintain, and it's _especially_ so when it's for small details rather than 
"big picture" issues.

I also consider this to be _exactly_ the same issue as translating kernel 
messages into another language (which people have also wanted to do), 
except the "other language" is a S390-specific "odd-speak" rather than a 
real language.

I have to say that I also dislike the technical implementation. I don't 
like having yet another printk() wrapper - your "kmsg_warn()" won't play 
well with people who have messages they want to print, but that use helper 
routines - or then you'd need to essentially change _every_ printk to a 
kmsg_xyz(). 

So if you want to have a hash (so that you can identify the _format_ 
string rather than the printed out message), I personally think you'd be 
better off thinking of it purely the same way as CONFIG_PRINTK_TIME, and 
just have a config option that disables or enables the hashing of the 
format string, the same way we have an option for disabling or enabling of 
the timestamping of the printk.

I also suspect that it would be better to not _print_ it, but only put it 
into the dmesg logs (the same way we do with the urgency level marker).

IOW, I think we could put a few lines of code in "vprintk" that just 
hashes ove 'fmt' and then adds that to the output.

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.

			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/