linux-kernel - Re: RFC: dynamic debug enhancements?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Aug 2011 10:23:11 -0400
From:	Jason Baron <jbaron@...hat.com>
To:	Joe Perches <joe@...ches.com>
Cc:	Jim Cromie <jim.cromie@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: RFC: dynamic debug enhancements?

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.
> 
> Another common thing was the use of various
> __FILE__, __func__, __LINE__ outputs.
> 
> I think __FILE__ is not particularly useful and
> can reasonably be replaced by KBUILD_MODNAME.
> 
> Perhaps it would be good to have options to
> enable these outputs with specific controls
> for dynamic_debug uses.
> 
> Maybe something like using a define similar to
> pr_fmt for what options are preselected for
> various ddebug outputs like:
> 
> #define DYNAMIC_DEBUG_DEFAULT_FLAGS 		\
> 	(_DPRINTK_FLAGS_INCL_MODNAME |		\
> 	 _DPRINTK_FLAGS_INCL_FUNCNAME |		\
> 	 _DPRINTK_FLAGS_INCL_LINENO)
> 
> 

Hi Joe,

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?

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