linux-kernel - Re: [PATCH] security: Use IS_ENABLED() instead of checking for built-in or module

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:	Thu, 14 Jul 2016 18:06:13 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	Casey Schaufler <casey@...aufler-ca.com>,
	Javier Martinez Canillas <javier@....samsung.com>
Cc:	linux-kernel@...r.kernel.org, "Serge E. Hallyn" <serge@...lyn.com>,
	linux-security-module@...r.kernel.org,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Eric Paris <eparis@...isplace.org>, selinux@...ho.nsa.gov,
	James Morris <james.l.morris@...cle.com>
Subject: Re: [PATCH] security: Use IS_ENABLED() instead of checking for
 built-in or module

On Thu, Jul 14, 2016 at 4:54 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
> On 7/14/2016 12:57 PM, Paul Moore wrote:
>> On Thu, Jul 14, 2016 at 12:30 PM, Casey Schaufler
>> <casey@...aufler-ca.com> wrote:
>>> On 7/14/2016 9:20 AM, Javier Martinez Canillas wrote:
>>>> Hello Casey,
>>>>
>>>> On 07/14/2016 12:17 PM, Casey Schaufler wrote:
>>>>> On 7/14/2016 9:00 AM, Javier Martinez Canillas wrote:
>>>>>> The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either
>>>>>> built-in or as a module, use that macro instead of open coding the same.
>>>>> Why?
>>>>
>>>> Why not? We have a macro for this so why is better to open coding it?
>>>
>>> Unless there is a real advantage to IS_ENABLED() over ifdef there
>>> is no value in making the change. Any change can introduce a problem,
>>> so we don't make changes based on "why not". It's called code churn.
>>
>> I think the IS_ENABLED() macro makes the code more readable by helping
>> abstract away some of the Kconfig/module details; not to mention it
>> provides some insulation from Kconfig changes (although I suppose it
>> is doubtful this will be a real issue anytime soon).
>>
>> Javier, if you want to respin this patch without the Smack changes
>> I'll merge it into the SELinux tree (not for the v4.8 merge window,
>> but for the next merge window).  However, if Casey changes his mind
>> and ACKs this patch, I'll go ahead and merge the original patch.
>
> Don't let me stand in the way. If you think it's worth
> doing go ahead and add my ACK.

I think it's a reasonable patch and I'm at that point in the day where
I'm looking for distractions so I just added it to the selinux#next
queue; once the merge window closes I'll rotate this into my next
branch.

-- 
paul moore
www.paul-moore.com