On Mon, 2014-05-05 at 13:35 -0700, Andrew Morton wrote:
> On Mon, 5 May 2014 10:43:05 -0400 Dan Streetman <ddstr...@ieee.org> wrote:
>
> > Replace pr_debug() in lib/plist.c test function plist_test() with
> > printk(KERN_DEBUG ...).
> >
> > Without DEBUG defined, pr_debug() is complied out, but the entire
> > plist_test() function is already inside CONFIG_DEBUG_PI_LIST, so
> > printk should just be used directly.
> >
> > --- a/lib/plist.c
> > +++ b/lib/plist.c
> > @@ -175,7 +175,7 @@ static int __init plist_test(void)
> > int nr_expect = 0, i, loop;
> > unsigned int r = local_clock();
> >
> > - pr_debug("start plist test\n");
> > + printk(KERN_DEBUG "start plist test\n");
>
> Now someone will come along and helpfully switch it back to pr_debug()
> again :(
>
> What about adding a #define DEBUG?
That can be unfortunate when there are other
#if DEBUG
some noisy or unnecessary code...
#endif
blocks in the same compilation unit.
> This aspect of pr_debug() is rather surprising and unfortunate and I
> guess we screwed it up.
meh.
It's been this way for quite awhile.
I have over long periods suggested adding
variants like pr_vdbg and pr_dbg_always.
https://lkml.org/lkml/2009/10/13/634
http://patchwork.ozlabs.org/patch/63513/
Never had much success or visibility.
> pr_debug() should unconditionally do the
> printk, just like pr_warn, pr_emerg, etc.
I think that would not be good.
That would set an expectation for dev_dbg which
has never been enabled unconditionally.
> And there should be a
> separate pr_debug_cond() which honours the DEBUG setting.
I think that's suboptimal.
> akpm3:/usr/src/linux-3.15-rc4> grep -r pr_debug . | wc -l
> 10286
>
> Boy, that's going to be a big patch ;)
$ git grep -E "\bprintk\s*\(s*KERN_DEBUG\b" | wc -l
4412
Not to mention all the macros that use those and are
then themselves used hundreds or thousands of times...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
