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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Documentation of kernel messages (Summary)
    ... suggested solutions for documentation / translation of kernel messages ... the messages should _be_ documentation. ... Use printk format string as message identifier ...
    (Linux-Kernel)
  • Documentation of kernel messages (Summary)
    ... suggested solutions for documentation / translation of kernel messages ... to the corresponding documentation / translation. ... Use printk format string as message identifier ...
    (Linux-Kernel)
  • Re: [GIT PULL/RESEND] kernel message catalog patches
    ... It's that I don't like out-of-line documentation. ... The farther away the documentation is from the source code ... tricks with two families of printk macros: ... In that case ALL printk messages would suddenly grow a hash. ...
    (Linux-Kernel)
  • Re: [RFC/PATCH] Documentation of kernel messages
    ... administrators want to have descriptions for Linux kernel messages. ... I'm not sure we want to make Linux more like z/* in this regard. ... monkeys to watch git-commits and resubmit documentation for every diff ... Does every printk need one of these? ...
    (Linux-Kernel)
  • Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
    ... kernel patch practice in 2.6.13-mm2 ... My objective is understandable good documentation, ... and I can tell you the simple reasons why. ... about debug parameters is simply obsolete! ...
    (Linux-Kernel)