linux-kernel - Re: Dynamic Debug module.ddebug fake param enhancements V4

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]

Message-Id: <201009280822.11675.bjorn.helgaas@hp.com>
Date:	Tue, 28 Sep 2010 08:22:11 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Thomas Renninger <trenn@...e.de>
Cc:	gregkh@...e.de, linux-kernel@...r.kernel.org, jbaron@...hat.com
Subject: Re: Dynamic Debug module.ddebug fake param enhancements V4

On Tuesday, September 28, 2010 06:25:18 am Thomas Renninger wrote:
> Greg: Do you mind pushing the first (1/4, V4) and the last (4/4)
> patch into your tree for linux-next and leave the two PNP patches
> out, please.
> 
> More PNP related discussion, below.
> 
> On Monday 27 September 2010 17:09:18 Bjorn Helgaas wrote:
> > On Monday, September 27, 2010 02:25:46 am Thomas Renninger wrote:
> > 
> > > What do you think (dev_dbg vs printk(KERN_DEBUG...)?
> ...
> > With the exception of the ones in pnp/resource.c that I want to convert
> > to dev_printk(KERN_DEBUG), I think all the pnp_dbg() uses are things
> > I used during PNP development and haven't ever needed since.
> 
> Ok. Sounds sane.
> I used the PNP parts as it nicely showed what the
> module.ddebug boot param is doing, but I agree it hasn't much
> advantage for PNP.
> 
> Whatabout compiling pnp in one module namespace, the first
> of the two PNP patches?

[2/4] looks reasonable to me.

> E.g. attached patch would be an on top patch which provides no
> functional change, just that a pnp.debug would be a module param:
> cat /sys/module/pnp/parameters/debug

As does the one below.

> ---------
> PNP: Set up pnp_debug via module and not via boot param.
> 
> Cleanup only, no functional change (pnp.debug can be enabled
> and disabled at runtime, but that's not a real enhancement).
> 
> This one depends on another PNP cleanup patch:
> PNP: Compile all pnp built-in stuff in one module namespace
> 
> Signed-off-by: Thomas Renninger <trenn@...e.de>
> 
> diff --git a/drivers/pnp/core.c b/drivers/pnp/core.c
> index 88b3cde..9801918 100644
> --- a/drivers/pnp/core.c
> +++ b/drivers/pnp/core.c
> @@ -218,10 +218,5 @@ subsys_initcall(pnp_init);
>  int pnp_debug;
>  
>  #if defined(CONFIG_PNP_DEBUG_MESSAGES)
> -static int __init pnp_debug_setup(char *__unused)
> -{
> -	pnp_debug = 1;
> -	return 1;
> -}
> -__setup("pnp.debug", pnp_debug_setup);
> +module_param_named(debug, pnp_debug, int, 0644);
>  #endif
> 
--
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/