[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <38fd40d03b030f9a60afe4445ddc0daca220e449.camel@linux.ibm.com>
Date: Sun, 26 Jun 2022 12:13:13 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: xiujianfeng <xiujianfeng@...wei.com>,
Ahmad Fatoum <a.fatoum@...gutronix.de>,
dmitry.kasatkin@...il.com, jmorris@...ei.org, serge@...lyn.com,
linux-integrity@...r.kernel.org,
linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next] evm: Use IS_ENABLED to initialize .enabled
On Tue, 2022-06-21 at 19:17 -0700, Eric Biggers wrote:
> On Tue, Jun 21, 2022 at 10:03:39AM -0400, Mimi Zohar wrote:
> > On Tue, 2022-06-21 at 18:58 +0800, xiujianfeng wrote:
> > > Hi, Ahmad
> > >
> > > 在 2022/6/7 14:06, Ahmad Fatoum 写道:
> > > > On 06.06.22 12:10, Xiu Jianfeng wrote:
> > > >> Use IS_ENABLED(CONFIG_XXX) instead of #ifdef/#endif statements to
> > > >> initialize .enabled, minor simplicity improvement.
> >
> > The difference between using ifdef's and IS_ENABLED is when the
> > decision is made - build time, run time. Please update the patch
> > description providing an explanation for needing to make the decision
> > at run time.
> >
> > thanks,
>
> IS_ENABLED() is a compile time constant. So the patch looks fine to me.
Thanks, Eric, for the clarification.
As LSMs are only builtin, why the need for using IS_ENABLED as opposed
to IS_BUILTIN?
#define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
thanks,
Mimi
Powered by blists - more mailing lists