Re: [PATCH] plist: replace pr_debug with printk in plist_test()

[Joe Perches]

On Mon, 2014-05-05 at 13:35 -0700, Andrew Morton wrote:
> On Mon,  5 May 2014 10:43:05 -0400 Dan Streetman <ddstreet@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/