Joe Perches <j...@perches.com> writes: > On Mon, 2016-12-12 at 23:22 +0100, Pavel Machek wrote: >> On Mon 2016-12-12 10:39:15, Joe Perches wrote: >> > On Mon, 2016-12-12 at 09:56 -0800, Nick Desaulniers wrote: >> > > A quick cleanup that passes scripts/checkpatch.pl -f <file>. > [] >> > > diff --git a/arch/x86/kernel/acpi/cstate.c >> > > b/arch/x86/kernel/acpi/cstate.c > [] >> > It's generally better not to convert >> > these printk(KERN_DEBUG uses. >> > >> > There are behavior differences between >> > printk(KERN_DEBUG ...); >> > and >> > pr_debug(...); >> > >> > The first will always be emitted as long >> > as the console level is appropriate. >> > >> > The second depends on a #define DEBUG >> > before it gets emitted or a kernel >> > with CONFIG_DYNAMIC_DEBUG enabled and >> > this entry specifically enabled in the >> > control file. >> >> Hmm. Perhaps pr_debug should be called pr_c_debug() or something? This >> is rather nice trap. > > Yeah, I've suggested veriants like pr_always_debug (from 2009) > http://lkml.iu.edu/hypermail/linux/kernel/0910.0/00399.html
The ability to strip the kernel from all debugging messages, or to keep them and dynamically enabling the interesting ones, are both important features *on top of* printk(KERN_DEBUG ...); If you add pr_c_debug() or whatever, then you'll only create a use case for another level of "strip this out". Back to square one. If this is a case of "my debug message is too important to let the user strip it from the kernel", then just use pr_info(). If not, then live with the additional debug level features leaving the control in the hands of the user. Personally, I want to be able to do dynamic debugging without having to manually filter out any unconditional debug messages. Please don't mess that up. There are more than enough levels for unconditional messages. we can afford to reserve KERN_DEBUG for the dynamic debug conditional ones. Thanks. Bjørn
