Re: [Xen-devel] [XEN PATCH 6/8] xen: Move CONFIG_INDIRECT_THUNK to Kconfig

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.12.2019 13:18, Anthony PERARD wrote:
> On Fri, Dec 13, 2019 at 12:13:53PM +0100, Jan Beulich wrote:
>> On 12.12.2019 19:27, Anthony PERARD wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -32,6 +32,9 @@ config ARCH_DEFCONFIG
>>>     string
>>>     default "arch/x86/configs/x86_64_defconfig"
>>>  
>>> +config INDIRECT_THUNK
>>> +   def_bool $(cc-option,-mindirect-branch-register)
>>
>> I'm not happy to see constructs like this appear. They leave a
>> "# CONFIG_... is not defined" in .config for no reason when
>> the expression evaluates to n.
> 
> For some reason, this doesn't happen. If $(CC) doesn't understand the
> option, the CONFIG_ doesn't appear at all in .config.
> 
> I guess "# CONFIG_... is not defined" comments are only useful for
> options that can be selected by users, so Kconfig would know not to ask
> the users again. So, for "options" that aren't for users, the comment
> doesn't need to exist.
> 
>> This may not matter much when
>> considering just one such line, but it will when we gain
>> dozens or hundreds. For options without prompts I think the
>> default should only ever be set to y (or m, which we don't
>> use). The above would then be written as
> 
> I think Kconfig developers have already done the work for that :-). So
> the construct def_bool y if $X isn't needed.

So I've checked - in Linux the longer construct is needed, while in
Xen it isn't. I can't currently explain why this is, but I take it
to mean that we're at risk of getting the stray extra lines emitted
whenever something in our Kconfig files changes in a way triggering
the same behavior as observed in Linux.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel