LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [GIT PULL/RESEND] kernel message catalog patches
Date: Mon, 27 Oct 2008 08:05:29 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.00.0810270750100.3386@nehalem.linux-foundation.org> (raw)
In-Reply-To: <1225101688.15777.6.camel@localhost>
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
next prev parent reply other threads:[~2008-10-27 15:12 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 [this message]
2008-10-27 15:52 ` Martin Schwidefsky
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.0810270750100.3386@nehalem.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=gregkh@suse.de \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=schwidefsky@de.ibm.com \
--subject='Re: [GIT PULL/RESEND] kernel message catalog patches' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).