LKML Archive on
help / color / mirror / Atom feed
From: Martin Schwidefsky <>
To: Linus Torvalds <>
Cc: Heiko Carstens <>,
	Andrew Morton <>,
	Greg Kroah-Hartman <>,,
Subject: Re: [GIT PULL/RESEND] kernel message catalog patches
Date: Mon, 27 Oct 2008 16:52:06 +0100	[thread overview]
Message-ID: <1225122726.15777.42.camel@localhost> (raw)
In-Reply-To: <>

On Mon, 2008-10-27 at 08:05 -0700, Linus Torvalds wrote:
> 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.

Yes, indeed. The farther away the documentation is from the source code
the harder it will be to maintain. That is why I would like to see it in
the linux source tree.

> 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.

The message tag would be the way to find the translation in some
database from the plain english output you'll find on the screen.

> 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(). 

Today I've replaced kmsg_xyz() with pr_xyz(). The current code now plays
tricks with two families of printk macros: dev_xyz() and pr_xyz().
If you ask Greg every device driver should be using dev_xyz() for its
printks anyway..

> 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.

In that case ALL printk messages would suddenly grow a hash. Which
precludes the use of the component name as part of the message since we
would need to add a component name for every single printk - that won't
Without a component name we are forced to use a larger number of bits
for the hash to avoid collisions. For 10,000 printks and a 32 bit hash
the likelyhood of a collision is already bigger than 2%, so we'd need
something bigger than 32 bit. With a component name in addition to the
hash you can split the printks into groups which greatly reduces the
danger of a collision.

> 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.

A dev_xyz() message would then look like this:

<level> <hash>: <driver-name> <device-name>: <the message text>

The prefix is rather lengthy, no ?

> 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.

The kmsg comments are already formatted in the kernel-doc style and you
can put the comment anywhere in the source file that contains the
printk. The Documentation/ is an extra path where the script looks for
the comments. I can easily drop that part. So yes, the concept is that
you can keep the message comment close to the printk.

blue skies,

"Reality continues to ruin my life." - Calvin.

  reply	other threads:[~2008-10-27 15:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-16 14:50 [GIT PULL] " Martin Schwidefsky
2008-10-17  7:59 ` Martin Schwidefsky
2008-10-21  9:21   ` [GIT PULL/RESEND] " Heiko Carstens
2008-10-23 15:35     ` Linus Torvalds
2008-10-23 21:04       ` Heiko Carstens
2008-10-23 21:37         ` Linus Torvalds
2008-10-24 15:50           ` Heiko Carstens
2008-10-26 19:26           ` Martin Schwidefsky
2008-10-26 19:12             ` Linus Torvalds
2008-10-27 10:01               ` Martin Schwidefsky
2008-10-27 15:05                 ` Linus Torvalds
2008-10-27 15:52                   ` Martin Schwidefsky [this message]
2008-10-27 16:19                     ` Theodore Tso
2008-10-27 16:27                       ` Randy Dunlap
2008-10-28  8:25                         ` Martin Schwidefsky
2008-10-27 16:03                   ` Alan Cox
2008-10-27 16:10                     ` Linus Torvalds
2008-10-27 16:35                       ` Alan Cox
2008-10-27 19:36                       ` Theodore Tso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1225122726.15777.42.camel@localhost \ \ \ \ \ \ \ \
    --subject='Re: [GIT PULL/RESEND] kernel message catalog patches' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).