linux-kernel - Re: [PATCH] ACPI: small formatting fixes

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: <87shpsi1xl.fsf@miraculix.mork.no>
Date:   Tue, 13 Dec 2016 11:00:22 +0100
From:   Bjørn Mork <bjorn@...k.no>
To:     Joe Perches <joe@...ches.com>
Cc:     Pavel Machek <pavel@....cz>,
        Nick Desaulniers <nick.desaulniers@...il.com>,
        rjw@...ysocki.net, len.brown@...el.com, tglx@...utronix.de,
        mingo@...hat.com, hpa@...or.com, x86@...nel.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ACPI: small formatting fixes

Joe Perches <joe@...ches.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