From: Peter Zijlstra <peterz@infradead.org>
To: Valdis.Kletnieks@vt.edu
Cc: akpm@linux-foundation.org, h-shimamoto@ct.jp.nec.com,
joe@perches.com, mingo@elte.hu, nooiwa@miraclelinux.com,
mm-commits@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [folded] kernelh-add-printk_ratelimited-and-pr_level_rl-rename.patch removed from -mm tree
Date: Wed, 16 Dec 2009 11:48:24 +0100 [thread overview]
Message-ID: <1260960504.17860.76.camel@laptop> (raw)
In-Reply-To: <25197.1260917095@localhost>
On Tue, 2009-12-15 at 17:44 -0500, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 15 Dec 2009 11:28:02 +0100, Peter Zijlstra said:
> > On Mon, 2009-12-14 at 17:08 -0800, akpm@linux-foundation.org wrote:
> > > s/_rl/_ratelimited/g
> >
> > do we feel this pr_* wankery is worth the hassle? I'd as soon send a
> > patch removing all this crap.
>
> pr_foo() instead of printk(KERN_FOO) is probably worth the hassle, as it
> allows more selective inclusion of messages if you're trying to build an
> embedded kernel. It's easy to say "I want pr_warning() to stay in, but
> lower levels compile to nothing". Trying to keep a 'printk(KERN_WARNING'
> while making a printk(KERN_DEBUG go away is just asking for some truly
> astounding pre-processor gyrations.
So we are depricating printk()?
Last time I asked that the answer was no, at which point there is
absolutely no point in using pr_* wankery.
And I much prefer the printk() thing, because
1) my fingers know it
2) it looks like the userspace printf thing
3) its an easier pattern to grep for
prev parent reply other threads:[~2009-12-16 10:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200912150108.nBF18TNx015047@imap1.linux-foundation.org>
2009-12-15 10:28 ` [folded] kernelh-add-printk_ratelimited-and-pr_level_rl-rename.patch removed from -mm tree Peter Zijlstra
2009-12-15 21:28 ` Andrew Morton
2009-12-15 22:44 ` Valdis.Kletnieks
2009-12-16 10:48 ` Peter Zijlstra [this message]
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=1260960504.17860.76.camel@laptop \
--to=peterz@infradead.org \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=h-shimamoto@ct.jp.nec.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mm-commits@vger.kernel.org \
--cc=nooiwa@miraclelinux.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox