[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1257839661.2377.33.camel@Joe-Laptop.home>
Date: Mon, 09 Nov 2009 23:54:21 -0800
From: Joe Perches <joe@...ches.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrew Morton <akpm@...ux-foundation.org>,
Naohiro Ooiwa <nooiwa@...aclelinux.com>,
Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>,
roland@...hat.com, Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>, oleg@...hat.com
Subject: Re: [PATCH] kernel.h: Add printk_ratelimited and pr_<level>_rl
On Tue, 2009-11-10 at 08:39 +0100, Ingo Molnar wrote:
> * Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> > Is there a reason for all this pr_ nonsense? will we depricate printk()?
> Yes, pr_*() has established itself as a printk shortcut. The benefits
> of: pr_info("stuff\n"); versus: printk(KERN_INFO "stuff\n");
> are sufficiently large:
> - it's shorter by 9 characters (more than a level of indentation)
> - you cannot forget to add a KERN_ prefix - which is required for 98%
> of all printks but which is forgotten from 50% of the submitted
> patches.
> so pr_*(), while named in a sucky way (all 2 letter abbrevs are sucky),
> has advantages, makes stuff more readable and reduces churn.
pr_*()s can be prefixed by pr_fmt
pr_*()s could save text space by storing pr_fmt once
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists