linux-kernel - Re: [PATCH] staging: ozwpan: Convert printk to dev

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: <51C9D818.1090702@atmel.com>
Date:	Tue, 25 Jun 2013 18:49:12 +0100
From:	Rupesh Gujare <rupesh.gujare@...el.com>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	<devel@...uxdriverproject.org>, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <shigekatsu.tateno@...el.com>
Subject: Re: [PATCH] staging: ozwpan: Convert printk to dev_dbg()

On 25/06/13 18:02, Greg KH wrote:
> On Tue, Jun 25, 2013 at 05:30:02PM +0100, Rupesh Gujare wrote:
>> convert all debug messages from printk to dev_dbg() & add kernel config to
>> enable/disable these messages during compilation.
> No, just use the built-in dynamic debug code in the kernel, no need to
> provide any new macros or functions or most importantly, no new Kconfig
> options.
>

New macro (oz_trace) is being used as pointer to "struct device *" is 
not available in all functions for dev_dbg() function.
Please let me know if there is better way to handle this, I will be 
happy to rework on this.

As well new Kconfig option was added to pass CFLAGS to compiler, so that 
dev_dbg will get compiled on system where DYNAMIC_DEBUG is not defined.
I was assuming that it is a standard practice, as I can find similar 
Kconfig option for other drivers. Or am I wrong in my understanding ?

Main idea here is to replace printk with dev_dbg(), which gives us 
option to enable individual log during runtime if DYNAMIC_DEBUG is 
enabled & provide mechanism to compile this when DYNAMIC_DEBUG is not 
enabled.

Again many of these logs will be removed in future, as currently there 
are too many logs which are not required, hence idea is to only change 
macro & then remove remaining logs in future.

-- 
Regards,
Rupesh Gujare

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