Message-Id: <20080430124506.0dd2a473.akpm@linux-foundation.org>
Date:	Wed, 30 Apr 2008 12:45:06 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jason Baron <jbaron@...hat.com>
Cc:	linux-kernel@...r.kernel.org, Greg KH <greg@...ah.com>
Subject: Re: [patch 0/3] dynamic_printk: new feature

On Tue, 29 Apr 2008 14:39:35 -0400
Jason Baron <jbaron@...hat.com> wrote:

> hi,
> 
> Add the ability to dynamically enable/disable pr_debug()/dev_dbg() in the
> kernel. Yes, these calls could be converted to printk(KERN_DEBUG), but there
> are enough to cause overhead. Additionally, the logs become difficult to read.
> This work is dependent on the CONFIG_DYNAMIC_PRINTK, which when enabled adds
> about 1% to the text size of the kernel. Mssages can be dynamically controlled
> by module:
> 
> echo "add module_name" > /sys/kernel/debug/dynamic_printk/modules
> echo "remove module_name" > /sys/kernel/debug/dynamic_printk/modules
> 
> There is also a special 'all' value that turns on all the debugging messages.
> This 'all' value can also be enabled during boot by passing 'dynamic_printk' on
> the kernel command line.
> 
> I hope that these patches are useful for people writing new kernel code, for
> system debugging and testing. In enabling the 'all' feature on the kernel I was
> running i got a bunch of messages...they are pretty interesting in and of
> themselves...they could point to error conditions, or further optimizations.
> 
> 

Without having looked at the implementation yet...

We should have done this ten years ago :(

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?



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?

> 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?

- 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?


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?


--
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