Messages in this thread | | | Date | Wed, 30 Apr 2008 17:01:50 -0400 | From | Jason Baron <> | 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
| |