Date:	Thu, 8 Dec 2011 12:10:44 -0500
From:	Jason Baron <jbaron@...hat.com>
To:	jim.cromie@...il.com
Cc:	greg@...ah.com, joe@...ches.com, bart.vanassche@...il.com,
	linux-kernel@...r.kernel.org, Thomas Renninger <trenn@...e.de>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH 18/25] dynamic_debug: Introduce global fake module param
 $module.dyndbg

On Tue, Dec 06, 2011 at 12:11:28PM -0700, jim.cromie@...il.com wrote:
> From: Jim Cromie <jim.cromie@...il.com>
> 
> Rework Thomas Renninger's $module.ddebug boot-time debugging feature,
> from https://lkml.org/lkml/2010/9/15/397
> 
> Extend dynamic-debug facility to work during module initialization:
> 
>   foo.dyndbg bar.dyndbg="$bar-query-string"
> 
> This patch introduces a 'fake' module parameter: $module.ddebug for
> all modules.  It is not explicitly added to each module, but is
> implemented as an unknown-parameter callback invoked by kernel/param's
> parse_one(), and it applies each module's query-string as if it were
> written to the $DBGFS/dynamic_debug/control file.
> 
> The module-name is added to the unknown-parameter callback signature
> and to its caller: parse_one().  This lets the common callback know
> what module its handling a common parameter for.
> 
> If no value is given (as in foo.dyndbg example above), "+p" is
> assumed, which enables all pr_debug callsites in the module.
> 
> The parameter is not shown in /sys/module/*/parameters, thus it does
> not use any resources.  Changes to the parameter are made via the
> control file.
> 
> Signed-off-by: Jim Cromie <jim.cromie@...il.com>
> CC: Thomas Renninger <trenn@...e.de>
> CC: Rusty Russell <rusty@...tcorp.com.au>
> ---
>  Documentation/dynamic-debug-howto.txt |   52 ++++++++++++++++++++++++++++++++-
>  include/linux/dynamic_debug.h         |   11 +++++++
>  include/linux/moduleparam.h           |    2 +-
>  init/main.c                           |    7 ++--
>  kernel/module.c                       |    3 +-
>  kernel/params.c                       |   10 ++++--
>  lib/dynamic_debug.c                   |   16 +++++++++-
>  7 files changed, 89 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt
> index 989a892..56e496a 100644
> --- a/Documentation/dynamic-debug-howto.txt
> +++ b/Documentation/dynamic-debug-howto.txt
> @@ -219,7 +219,7 @@ Note also that there is no convenient syntax to remove all
>  the flags at once, you need to use "-flmpt".
>  
>  
> -Debug messages during boot process
> +Debug messages during Boot Process
>  ==================================
>  
>  To be able to activate debug messages during the boot process,
> @@ -238,6 +238,45 @@ PCI (or other devices) initialization also is a hot candidate for using
>  this boot parameter for debugging purposes.
>  
>  
> +Debug Messages at Module Initialization Time
> +============================================
> +
> +Enabling a module's debug messages via debug control file only works
> +once the module is loaded; too late for callsites in init functions.
> +And when module is unloaded, debug flag settings for the module are
> +lost.  Instead, a "dyndbg" module parameter can be passed:
> +
> +	- via kernel boot parameter: (this form works on built-ins too)
> +	  module.dyndbg=+mfp
> +	  module.dyndbg	# defaults to +p
> +
> +	- as an ordinary module parameter via modprobe
> +	  modprobe module dyndbg=+pmfl
> +	  modprobe module dyndbg # defaults to +p
> +
> +	- or the parameter can be used permanently via modprobe.conf(.local)
> +	  options module dyndbg=+pmflt
> +	  options module dyndbg # defaults to +p
> +
> +The $modname.dyndbg="value" should exclude "module $modname", as the
> +$modname is taken from the param-name, and only 1 spec of each type is
> +allowed.
> +
> +The dyndbg option is not implemented as an ordinary module parameter
> +and thus will not show up in /sys/module/module_name/parameters/dyndbg
> +The settings can be reverted later via the sysfs interface if the
> +debug messages are no longer needed:
> +
> +      echo "module module_name -p" > <debugfs>/dynamic_debug/control
> +
> +$module.dyndbg="..." on boot-line works on built-in modules as well as
> +those loaded by modprobe (from either early or normal userspace), and
> +somewhat overlaps debug_query functionality.
> +
> +Modprobed modules get dyndbg flags given on boot-line after those
> +given via modprobe (either explicitly, or from /etc/modprobe.d/*).
> +This can surprise if boot-line arg subtracts flags.
> +
>  Examples
>  ========
>  
> @@ -264,3 +303,14 @@ nullarbor:~ # echo -n 'func svc_process -p' >
>  // enable messages for NFS calls READ, READLINK, READDIR and READDIR+.
>  nullarbor:~ # echo -n 'format "nfsd: READ" +p' >
>  				<debugfs>/dynamic_debug/control
> +
> +// boot-args example, with newlines and comments
> +Kernel command line: ... 
> +  ddebug_query="func i2c_del_adapter +p; func tboot_probe +p"
> +  dynamic_debug.verbose=1 		// see whats going on
> +  nouveau.dyndbg 			// implicit =+p
> +  tsc_sync.dyndbg=+p 			// builtin on my kernel
> +  i2c_core.dyndbg=+p			// loaded by udev
> +  *.dyndbg="=_"				// wildcard applies to builtins
> +  k10temp.dyndbg="+p # comment in query is stripped "
> +  pnp.dyndbg="func pnpacpi_get_resources +p; func pnp_assign_mem +p" # multi

I see you've added docs for the 'dyndbg' kernel command-line options,
but then I don't see any changes in the code to 'unkown_bootoption'.
What am I missing?

Thanks,

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

Powered by blists - more mailing lists