[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <99d2b96e-c1bc-52f9-c52b-f7577f9011b3@huawei.com>
Date: Wed, 29 Jun 2022 11:59:58 +0800
From: xiujianfeng <xiujianfeng@...wei.com>
To: Mimi Zohar <zohar@...ux.ibm.com>,
Eric Biggers <ebiggers@...nel.org>
CC: 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
在 2022/6/27 0:13, Mimi Zohar 写道:
> 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,
I think IS_ENALBED() is a bit more generic, maybe. here is another
example in rcutorture.c
which uses IS_ENABLED() to initialize the member in structure:
static struct rcu_torture_ops rcu_ops = {
...
.can_boost = IS_ENABLED(CONFIG_RCU_BOOST),
...
};
Do you want me to change IS_ENABLED() to IS_BUILTIN()?
>
> Mimi
>
> .
Powered by blists - more mailing lists