Re: [patch 0/3] dynamic_printk: new feature
- From: Jason Baron <jbaron@xxxxxxxxxx>
- Date: Wed, 30 Apr 2008 17:01:50 -0400
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- [patch 0/3] dynamic_printk: new feature
- From: Jason Baron
- Re: [patch 0/3] dynamic_printk: new feature
- From: Andrew Morton
- [patch 0/3] dynamic_printk: new feature
- Prev by Date: Re: Some sort corruption of my Thermal Subsystem after suspend to ram
- Next by Date: Re: [patch 0/3] dynamic_printk: new feature
- Previous by thread: Re: [patch 0/3] dynamic_printk: new feature
- Next by thread: Re: [patch 0/3] dynamic_printk: new feature
- Index(es):
Relevant Pages
|
