From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: debian-kernel@lists.debian.org, linux-m68k@vger.kernel.org,
Thorsten Glaser <tg@debian.org>,
linux-kernel@vger.kernel.org, Joe Perches <joe@perches.com>
Subject: Re: [PATCH] m68k/irq: don't use pr_crit in an header
Date: Sun, 18 Dec 2011 11:42:48 +0100 [thread overview]
Message-ID: <20111218104248.GS24496@pengutronix.de> (raw)
In-Reply-To: <CAMuHMdXyf_ofM+y6yKrzftyKTOyrSKzW7fUVAJyY6XTV_FVhNA@mail.gmail.com>
Hi Geert,
(thanks for adding Joe to Cc:, I noticed that when I wanted to add him
myself :-)
On Sun, Dec 18, 2011 at 11:32:21AM +0100, Geert Uytterhoeven wrote:
> 2011/12/17 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> > Using pr_crit in an header results in funny messages. Consider
> >
> > #define pr_fmt(fmt) "mydriver: " fmt
> > #include <linux/hardirq.h>
> >
> > which makes the message from ack_bad_irq
> >
> > mydriver: unexpected IRQ trap...
> >
> > so better use plain printk with KERN_CRIT directly.
>
> Yep, that's expected behavior, as defining pr_fmt() modifies all kernel messages
> generated from that module.
I'm aware it is expected, I only wondered if it is also desirable to
have messages in headers modified depending on the module the header is
included in.
> > This fixes a build problem on m68k with aufs3 en passant because the
> > latter builds with
> >
> > ccflags-y += -D'pr_fmt(fmt)=AUFS_NAME"\040%s:%d:%s[%d]:\040"fmt,__func__,__LINE__,current->comm,current->pid'
> >
> > without providing AUFS_NAME early enough for ack_bad_irq (which is the
> > problem of aufs).
>
> Isn't this a problem with (out of tree) aufs?
> Why does it put a define that relies on an (apparently sometimes still
> undefined)
> variable on the build command line?
This is definitily a bug in aufs that needs fixing independant of the
issue of using or not using pr_... in headers.
> Any header may contain calls to pr_*().
>
> > Cc: Thorsten Glaser <tg@debian.org>
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > arch/m68k/include/asm/hardirq.h | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/m68k/include/asm/hardirq.h b/arch/m68k/include/asm/hardirq.h
> > index db30ed2..1f652e0 100644
> > --- a/arch/m68k/include/asm/hardirq.h
> > +++ b/arch/m68k/include/asm/hardirq.h
> > @@ -20,7 +20,7 @@
> >
> > static inline void ack_bad_irq(unsigned int irq)
> > {
> > - pr_crit("unexpected IRQ trap at vector %02x\n", irq);
> > + printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
>
> Nack. Nowadays pr_crit(...) is recommended over "printk(KERN_CRIT ...)".
I know that, I just wonder if the proponents of this recommendation are
aware of the issue when using pr_* in headers. Joe?
> Besides, there are (albeit not that many yet) other callers of pr_*() in
> header files. Do you plan to revert them to printk(), too?
That depends on the outcome of this discussion.
> Please fix aufs instead. Thanks!
I already provided a patch for that, too. (Currently only on the Debian
kernel ML.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20111218104248.GS24496@pengutronix.de
WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: debian-kernel@lists.debian.org, linux-m68k@vger.kernel.org,
Thorsten Glaser <tg@debian.org>,
linux-kernel@vger.kernel.org, Joe Perches <joe@perches.com>
Subject: Re: [PATCH] m68k/irq: don't use pr_crit in an header
Date: Sun, 18 Dec 2011 11:42:48 +0100 [thread overview]
Message-ID: <20111218104248.GS24496@pengutronix.de> (raw)
In-Reply-To: <CAMuHMdXyf_ofM+y6yKrzftyKTOyrSKzW7fUVAJyY6XTV_FVhNA@mail.gmail.com>
Hi Geert,
(thanks for adding Joe to Cc:, I noticed that when I wanted to add him
myself :-)
On Sun, Dec 18, 2011 at 11:32:21AM +0100, Geert Uytterhoeven wrote:
> 2011/12/17 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> > Using pr_crit in an header results in funny messages. Consider
> >
> > #define pr_fmt(fmt) "mydriver: " fmt
> > #include <linux/hardirq.h>
> >
> > which makes the message from ack_bad_irq
> >
> > mydriver: unexpected IRQ trap...
> >
> > so better use plain printk with KERN_CRIT directly.
>
> Yep, that's expected behavior, as defining pr_fmt() modifies all kernel messages
> generated from that module.
I'm aware it is expected, I only wondered if it is also desirable to
have messages in headers modified depending on the module the header is
included in.
> > This fixes a build problem on m68k with aufs3 en passant because the
> > latter builds with
> >
> > ccflags-y += -D'pr_fmt(fmt)=AUFS_NAME"\040%s:%d:%s[%d]:\040"fmt,__func__,__LINE__,current->comm,current->pid'
> >
> > without providing AUFS_NAME early enough for ack_bad_irq (which is the
> > problem of aufs).
>
> Isn't this a problem with (out of tree) aufs?
> Why does it put a define that relies on an (apparently sometimes still
> undefined)
> variable on the build command line?
This is definitily a bug in aufs that needs fixing independant of the
issue of using or not using pr_... in headers.
> Any header may contain calls to pr_*().
>
> > Cc: Thorsten Glaser <tg@debian.org>
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > arch/m68k/include/asm/hardirq.h | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/m68k/include/asm/hardirq.h b/arch/m68k/include/asm/hardirq.h
> > index db30ed2..1f652e0 100644
> > --- a/arch/m68k/include/asm/hardirq.h
> > +++ b/arch/m68k/include/asm/hardirq.h
> > @@ -20,7 +20,7 @@
> >
> > static inline void ack_bad_irq(unsigned int irq)
> > {
> > - pr_crit("unexpected IRQ trap at vector %02x\n", irq);
> > + printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
>
> Nack. Nowadays pr_crit(...) is recommended over "printk(KERN_CRIT ...)".
I know that, I just wonder if the proponents of this recommendation are
aware of the issue when using pr_* in headers. Joe?
> Besides, there are (albeit not that many yet) other callers of pr_*() in
> header files. Do you plan to revert them to printk(), too?
That depends on the outcome of this discussion.
> Please fix aufs instead. Thanks!
I already provided a patch for that, too. (Currently only on the Debian
kernel ML.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2011-12-18 10:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-16 14:42 aufs vs. m68k conflict, please advice Thorsten Glaser
2011-12-16 16:48 ` Ben Hutchings
2011-12-16 17:15 ` Thorsten Glaser
2011-12-17 14:28 ` Thorsten Glaser
2011-12-17 16:24 ` Thorsten Glaser
2011-12-17 16:29 ` Ben Hutchings
2011-12-17 18:49 ` Uwe Kleine-König
2011-12-17 19:00 ` Thorsten Glaser
2011-12-17 19:57 ` Uwe Kleine-König
2011-12-17 20:09 ` [PATCH] m68k/irq: don't use pr_crit in an header Uwe Kleine-König
2011-12-17 21:19 ` Thorsten Glaser
2011-12-18 10:32 ` Geert Uytterhoeven
2011-12-18 10:42 ` Uwe Kleine-König [this message]
2011-12-18 10:42 ` Uwe Kleine-König
2011-12-18 17:06 ` Joe Perches
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=20111218104248.GS24496@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=debian-kernel@lists.debian.org \
--cc=geert@linux-m68k.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
--cc=tg@debian.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.