public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jean Delvare" <khali@linux-fr.org>
To: jengelh@computergmbh.de, joe@perches.com
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	mm-commits@vger.kernel.org, adaplas@pol.net, greg@kroah.com,
	jeff@garzik.org
Subject: Re: + remove-current-defines-and-uses-of-pr_err-add-pr_emerg.patch added to -mm tree
Date: Sat, 4 Aug 2007 18:47:50 +0200 (CEST)	[thread overview]
Message-ID: <0H03p0ll.1186246070.5043630.khali@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0708041141560.11760@fbirervta.pbzchgretzou.qr>


Hi Jan, Joe,

On 8/4/2007, "Jan Engelhardt" <jengelh@computergmbh.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@perches.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

  reply	other threads:[~2007-08-04 16:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <tI4NY5SL.1186153543.0764100.khali@localhost>
2007-08-03 22:16 ` + remove-current-defines-and-uses-of-pr_err-add-pr_emerg.patch added to -mm tree Joe Perches
2007-08-04  9:43   ` Jan Engelhardt
2007-08-04 16:47     ` Jean Delvare [this message]
2007-08-07 16:10       ` Joe Perches
2007-08-07 16:16         ` Jan Engelhardt
2007-08-07 20:19   ` Andrew Morton
2007-08-08 20:02     ` Jean Delvare
2007-08-08 20:31       ` Joe Perches
2007-08-08 20:39         ` Jan Engelhardt
2007-08-08 21:36           ` Joe Perches
2007-08-08 21:57             ` Jan Engelhardt
2007-08-08 22:21               ` Joe Perches
2007-08-10 20:22                 ` Jean Delvare

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=0H03p0ll.1186246070.5043630.khali@localhost \
    --to=khali@linux-fr.org \
    --cc=adaplas@pol.net \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=jeff@garzik.org \
    --cc=jengelh@computergmbh.de \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mm-commits@vger.kernel.org \
    /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