First off, I agree with Andrew, this is a very welcome thing to do.  If
there's anything I can do to help this out, please let me know.

On Wed, Apr 30, 2008 at 05:01:50PM -0400, Jason Baron wrote:
quoted text
> 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.

That's a good first start :)

Lots of the existing printk() type wrappers can also use the dev_*
versions as well (like the ALSA ones for example.)  So it might be
easier to focus on the existing users of these two functions, and then
work to convert the other different variants over to the dev_printk ones
where possible and d_printk where not (you don't always have a struct
device to use at the moment, which is required by dev_printk)

If you want to start with the USB core and drivers, I'll be glad to help
ensure those patches go in as well.

thanks,

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