Re: [patch 0/3] dynamic_printk: new feature

[Joe Perches <joe@perches.com>]

On Wed, 2008-04-30 at 12:45 -0700, Andrew Morton wrote: 
> 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've done that.
There have been many attempts at this.

http://lkml.org/lkml/2007/9/22/110
http://lkml.org/lkml/2007/9/27/274

It's not particularly difficult.
It's just a few scripts and some message massaging.
It's also a lot of what some call unnecessary churn.
I think it useful though.

I also have scripts to remove file/function/line numbers
from messages and use a generic method to integrate and
optionally display them via pr_<level>.

akin to:

#define pr_info(fmt, arg...) \
do { \
	char prefix[MAX_PREFIX_LEN]; \
	if (pr_enabled(prefix, sizeof(prefix), PR_INFO)) { \
		printk("%s" fmt, prefix, ##arg); \
	} \
} while (0)

where pr_enabled optionally formats KBUILD_MODNAME/__func__/__LINE__
and of course <level> to prefix with appropriate
CONFIG_PR_USE_MODNAME/FUNCTION/LINE controls for
embedded size minimization when kallsyms is not
available.

pr_enabled can also be #defined to 0 to eliminate
the strings and printk calls.

> - Your design handles a boolean on/off control.  But some code implements
>   a verbosity-level control.  Thoughts on this?

It seems there is still resistance to even ethtool style
msglevel.

Extending Jason's approach to test a module message level
seems simple enough and could/should be universal.

I think that message rate limiting should also be done here.
Also I think this facility would help in localization.

> But we will need to design it carefully first.

Agreed.  The "useless churn!" cries need also to be ignored
or at least damped down.

I'd also like to consider including mechanisms to
consolidate what are now consecutive calls to printk
to print partial lines into block start/end calls.
Perhaps pr_start, pr_cont, pr_end.

These calls should never fail under memory pressure.

Vegard Nossum had what I think is a good idea to
include a pointer to a printk reassembly buffer
in struct task_struct.

That could remove the need to pass round a pointer
when using block style printk calls.  

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

If you're referring to include/sound/core.h, it seems simple enough.

Would it be accepted though?