2011/12/17 Uwe Kleine-König <[email protected]>: > 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. > 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? Any header may contain calls to pr_*(). > Cc: Thorsten Glaser <[email protected]> > Signed-off-by: Uwe Kleine-König <[email protected]> > --- > 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 ...)". Besides, there are (albeit not that many yet) other callers of pr_*() in header files. Do you plan to revert them to printk(), too? Please fix aufs instead. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/camuhmdxyf_ofm+y6ykrzftyktoyrskzw7fuvajyy6xtv_fv...@mail.gmail.com
