Message-ID: <20080430210147.GA5616@redhat.com>
Date:	Wed, 30 Apr 2008 17:01:50 -0400
From:	Jason Baron <jbaron@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, Greg KH <greg@...ah.com>
Subject: Re: [patch 0/3] dynamic_printk: new feature

On Wed, Apr 30, 2008 at 12:45:06PM -0700, Andrew Morton wrote:
> We're now in the situation where numerous different subsystems have
> implemented private mechnisms for tuning their printk verbosity levels.
> 
> Have you taken a look across the tree with a view to converting some of
> them?  If so, how sizeable/messy/feasible would that task be?
> 
> 

i really only focused on pr_debug()/dev_dbg(), with an eye towards
widening the scope as we go...but I agree that it would be nice to
understand the scope for the start...i find ~5000 call sites to
dprintk(), which would be ideal candidates for this type of
infrastructure.

> 
> The situation is far, far worse with compile-time debugging selection.  We
> have over two hundred different implementations of dprintk!
> 
> Have you considered the feasibility of ploddingly converting each of those
> drivers, one at a time over to the new infrastructure?  Because that's what
> we should do, I'm afraid.
> 
> An implication of this is that once a dprintk-using driver has been
> converted over to use your new infrastructure, it should still be possible
> to fully disable the debugging at compile time.  Do you handle that?
> 

that's correct. the way i've handled this in the patch is:

if DEBUG 
	you get the current compiled in behavior per .c file
elif DYNAMIC_PRINTK
	you get the dynamic runtime configurable debugging
else
	its compiled out

> > If this patch is accepted, i'd like to convert the myriad 'debug' printks -
> > DEBUGP(), dprintk(), to a standard format, either pr_debug() or dev_dbg(), to
> > hook into this mechanism.
> 
> ah, so you have looked.  How nasty will it be?
> 
> 
> A couple of things:
> 
> - Your design handles a boolean on/off control.  But some code implements
>   a verbosity-level control.  Thoughts on this?
> 

right, i think though it could easily be extended to level control.
Basically the patch associates the on/off per KBUILD_MODNAME, however we
could also associate a level per KBUILD_MODNAME. This level could be set
either by the generic debugfs interface, via module parameters at module
load time, or in the the module __init sections as appropriate.


> - I expect that other code implements a field-selector control, for the
>   lack of a better term: an greater-than-one number of separate boolean
>   controls.  How to handle this?
> 
> 

hmmm...i think this is handled by having the driver call the conditions
in its scope and then call out to the generic infrastructure if the
conditions are met.

> Thanks for working on this.  If we can get this underway and get a decent
> amount of conversion done, it will be a huuuuuuuuuuuuge cleanup to the
> kernel.  But we will need to design it carefully first.
> 
> I guess one good testcase would be ALSA.  It has pretty fancy debugging
> control (which I apparently have never been smart enough to understand). 
> Did you take a look at what they're doing, with a view to
> can-we-switch-ALSA-to-use-this?
> 
> 

ok. i'll take a more detailed look at the pontentially wider scope of this change.

thanks,

-Jason

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists