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