From: Ingo Molnar <mingo@elte.hu>
To: Daniele Pizzoni <auouo@tin.it>
Cc: kernel-janitors <kernel-janitors@lists.osdl.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: [KJ] Re: [PATCH 0/8] replacing/fixing printk with pr_debug/pr_info
Date: Mon, 18 Oct 2004 10:36:33 +0000 [thread overview]
Message-ID: <20041018103633.GA6792@elte.hu> (raw)
In-Reply-To: <1098067288.2892.293.camel@pdp11.tsho.org>
[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]
* Daniele Pizzoni <auouo@tin.it> wrote:
> On dom, 2004-10-17 at 18:19, Ingo Molnar wrote:
> > [...]
> >
> > 1) be careful, there is no inconsistency here. It's a printk that doesnt
> > end in a "\n" in the first line.
>
> You're right, my fault and a big one!
>
> Anyway I'm going to ask some questions.
> There's nothing wrong with Dprintk or dprintk. I simply found a
> request to do so on the janitors TODO list. I found out that in
> kernel.h there was really a pr_debug macro and I used it.
ok.
> The rationale is that in the kernel there are lots of custom dprintk,
> Dprintk, DPRINTK, etc that we need a bit of housekeeping, I think.
> Anyway I didn't like pr_info either (why not a pr_notice...?) but I
> used it: it was in kernel.h I assumed it was for good.
ok - pr_debug() is ok i think for the APIC code. It pairs well with the
other variants: pr_notice(), etc.
> I need a bit of advice now: should I forget about printks' levels,
> consistency and focus on other issues or with a bit of work these
> patches may became worth of?
i'd suggest to first do the Dprintk -> pr_debug replacement patch with
as few output changes as possible. (output changes are unavoidable when
converting a \n-less printout.) Then do any format cleanups in a
separate patch.
(some of your other comments about 'spurious' whitespaces need a
double-check too, sometimes they are done for formatting reasons. So
always take a look at the log output before changing it.)
Ingo
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Daniele Pizzoni <auouo@tin.it>
Cc: kernel-janitors <kernel-janitors@lists.osdl.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/8] replacing/fixing printk with pr_debug/pr_info in arch/i386 - intro
Date: Mon, 18 Oct 2004 12:36:33 +0200 [thread overview]
Message-ID: <20041018103633.GA6792@elte.hu> (raw)
In-Reply-To: <1098067288.2892.293.camel@pdp11.tsho.org>
* Daniele Pizzoni <auouo@tin.it> wrote:
> On dom, 2004-10-17 at 18:19, Ingo Molnar wrote:
> > [...]
> >
> > 1) be careful, there is no inconsistency here. It's a printk that doesnt
> > end in a "\n" in the first line.
>
> You're right, my fault and a big one!
>
> Anyway I'm going to ask some questions.
> There's nothing wrong with Dprintk or dprintk. I simply found a
> request to do so on the janitors TODO list. I found out that in
> kernel.h there was really a pr_debug macro and I used it.
ok.
> The rationale is that in the kernel there are lots of custom dprintk,
> Dprintk, DPRINTK, etc that we need a bit of housekeeping, I think.
> Anyway I didn't like pr_info either (why not a pr_notice...?) but I
> used it: it was in kernel.h I assumed it was for good.
ok - pr_debug() is ok i think for the APIC code. It pairs well with the
other variants: pr_notice(), etc.
> I need a bit of advice now: should I forget about printks' levels,
> consistency and focus on other issues or with a bit of work these
> patches may became worth of?
i'd suggest to first do the Dprintk -> pr_debug replacement patch with
as few output changes as possible. (output changes are unavoidable when
converting a \n-less printout.) Then do any format cleanups in a
separate patch.
(some of your other comments about 'spurious' whitespaces need a
double-check too, sometimes they are done for formatting reasons. So
always take a look at the log output before changing it.)
Ingo
next prev parent reply other threads:[~2004-10-18 10:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-17 16:13 [KJ] [PATCH 0/8] replacing/fixing printk with pr_debug/pr_info in Daniele Pizzoni
2004-10-17 17:10 ` [PATCH 0/8] replacing/fixing printk with pr_debug/pr_info in arch/i386 - intro Daniele Pizzoni
2004-10-17 16:19 ` [KJ] Re: [PATCH 0/8] replacing/fixing printk with pr_debug/pr_info Ingo Molnar
2004-10-17 16:19 ` [PATCH 0/8] replacing/fixing printk with pr_debug/pr_info in arch/i386 - intro Ingo Molnar
2004-10-17 18:10 ` [KJ] Re: [PATCH 0/8] replacing/fixing printk with pr_debug/pr_info Geert Uytterhoeven
2004-10-17 18:10 ` [PATCH 0/8] replacing/fixing printk with pr_debug/pr_info in arch/i386 - intro Geert Uytterhoeven
2004-10-17 18:23 ` Joe Perches
2004-10-17 18:34 ` Geert Uytterhoeven
2004-10-18 1:44 ` [KJ] Re: [PATCH 0/8] replacing/fixing printk with pr_debug/pr_info Daniele Pizzoni
2004-10-18 2:41 ` [PATCH 0/8] replacing/fixing printk with pr_debug/pr_info in arch/i386 - intro Daniele Pizzoni
2004-10-18 10:36 ` Ingo Molnar [this message]
2004-10-18 10:36 ` Ingo Molnar
2004-10-18 12:09 ` [KJ] Re: [PATCH 0/8] replacing/fixing printk with pr_debug/pr_info Daniele Pizzoni
2004-10-18 12:59 ` [PATCH 0/8] replacing/fixing printk with pr_debug/pr_info in arch/i386 - intro Daniele Pizzoni
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=20041018103633.GA6792@elte.hu \
--to=mingo@elte.hu \
--cc=auouo@tin.it \
--cc=kernel-janitors@lists.osdl.org \
--cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.