Messages in this thread | | | Subject | Re: [patch 0/3] dynamic_printk: new feature | From | Joe Perches <> | Date | Wed, 30 Apr 2008 13:54:26 -0700 |
| |
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?
| |