[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0H03p0ll.1186246070.5043630.khali@localhost>
Date: Sat, 4 Aug 2007 18:47:50 +0200 (CEST)
From: "Jean Delvare" <khali@...ux-fr.org>
To: jengelh@...putergmbh.de, joe@...ches.com
CC: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
mm-commits@...r.kernel.org, adaplas@....net, greg@...ah.com,
jeff@...zik.org
Subject: Re: + remove-current-defines-and-uses-of-pr_err-add-pr_emerg.patch added to -mm tree
Hi Jan, Joe,
On 8/4/2007, "Jan Engelhardt" <jengelh@...putergmbh.de> wrote:
>On Aug 3 2007 15:16, Joe Perches wrote:
>>On Fri, 2007-08-03 at 17:05 +0200, Jean Delvare wrote:
>>> Fine with me, but this first patch should still be correct per se.
>>
>>Add new pr_<level> printk(KERN_<level> fmt "\n", ##arg) to kernel.h
>>pr_info and pr_debug are unchanged
>>Remove local pr_err #defines
>>Convert current uses of pr_err
>>
>>Signed-off-by: Joe Perches <joe@...ches.com>
>>
>>diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>>index 4300bb4..6447072 100644
>>--- a/include/linux/kernel.h
>>+++ b/include/linux/kernel.h
>>@@ -229,20 +229,24 @@ extern void print_hex_dump_bytes(const char *prefix_str, int prefix_type,
>> void *buf, size_t len);
>> #define hex_asc(x) "0123456789abcdef"[x]
>>
>>+#define pr_emerg(fmt, arg...) printk(KERN_EMERG fmt "\n", ##arg)
>>+#define pr_alert(fmt, arg...) printk(KERN_ALERT fmt "\n", ##arg)
>>+#define pr_crit(fmt, arg...) printk(KERN_CRIT fmt "\n", ##arg)
>>+#define pr_err(fmt, arg...) printk(KERN_ERR fmt "\n", ##arg)
>>+#define pr_warn(fmt, arg...) printk(KERN_WARNING fmt "\n", ##arg)
>>+#define pr_notice(fmt, arg...) printk(KERN_NOTICE fmt "\n", ##arg)
>>+#define pr_info(fmt, arg...) printk(KERN_INFO fmt, ##arg)
>>+
>
>Ugh. What do we have printk for then? I do not like this.
>For pr_debug() it makes sense because its semantics change with
>-DDEBUG and -UDEBUG, but for these pr_()s it does not seem so.
I think I agree with Jan here, I see no fundamental need for these
additional macros. But if they are really added, then they should follow
the same standard as pr_debug() and pr_info(), that is: no "\n" added
automatically. Otherwise this will become quite messy.
Thanks,
--
Jean Delvare
-
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