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]

Date:	Tue, 28 Sep 2010 14:25:18 +0200
From:	Thomas Renninger <trenn@...e.de>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	gregkh@...e.de, linux-kernel@...r.kernel.org, jbaron@...hat.com
Subject: Re: Dynamic Debug module.ddebug fake param enhancements V4

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?
I do not see an urgent need/advantage, it would just be a general
cleanup.
PNP could then make use of moduleparam.h interface instead of using
__setup(..).

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

Again there is not much use for this with pnp as all should be
processed at boot time. But theoretically one could enable pnp.debug
at runtime :) (or it should get hidden with 0000 perms if not needed).
It's more a general cleanup, further pnp boot params can be
pnp.xy module params then.

Bjoern: If you like them I can repost these two:
(PNP build in one module namespace and below)

        Thomas

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