Messages in this thread | | | From | Jim Cromie <> | Date | Mon, 29 Aug 2011 12:21:53 -0600 | Subject | Re: RFC: dynamic debug enhancements? |
| |
On Tue, Aug 23, 2011 at 7:00 PM, Joe Perches <joe@perches.com> wrote: > On Tue, 2011-08-23 at 10:23 -0400, Jason Baron wrote: >> On Sun, Aug 21, 2011 at 05:15:43PM -0700, Joe Perches wrote: >> > I recently went through drivers/media and updated >> > lots of calls to pr_<level>. >> > A common pattern for debugging there and elsewhere >> > treewide is the use of macros like: >> > #define dprintk(level, fmt, ...) \ >> > do { \ >> > if (level > [some_modparam_var]) \ >> > pr_debug(fmt, ##__VA_ARGS__); \ >> > } while (0) >> > and >> > #define dprintk(mask, fmt, ...) \ >> > do { \ >> > if (mask & [some_modparam_var]) \ >> > pr_debug(fmt, ##__VA_ARGS__); \ >> > } while (0) >> > It might be useful to have standardized calls >> > like pr_debug_level and pr_debug_mask instead >> > of multiple hand-rolled variants treewide. > [] >> looks interesting. I'm wondering how we handle module parameters though? >> In the dynamic debug disabled case, we'd have to standardize the module >> params names. And for the dynamic debug enabled case, I'm not sure how >> we would honor those module params? > > One possibility would be to require a #define > before use. > > Something like the DEBUG_VARIABLE used in > drivers/media/ and include/media/. > > Maybe something like: > > #define DYNAMIC_DEBUG_LEVEL_VARIABLE module_var_foo > and/or > #define DYNAMIC_DEBUG_MASK_VARIABLE module_var_bar > > and > > $ echo 'module <foo> mask <n>' > <debugfs>/dynamic_debug/control > and > $ echo 'module <foo> level <n>' > <debugfs>/dynamic_debug/control > > could work to set the module control variable too. > > >
how about just passing in condition directly ?
#define pr_dbg_if( cond, fmt, ... ) \ do { \ if (cond) \ pr_debug(fmt, ##__VA_ARGS__); \ } while (0)
this will serve both mask and level, and could underlie both of them, and its clear - no hidden checks against a variable named elsewhere. -- 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/
| |