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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.02.2020 18:13, Anthony PERARD wrote:
> On Tue, Feb 18, 2020 at 05:43:30PM +0100, Jan Beulich wrote:
>> 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.
> 
> Which version of Linux?

5.5

> Did you test with "def_bool" as the sole item in the config entry?

This

config CC_IS_CLANG
        def_bool $(success,$(CC) --version | head -n 1 | grep -q clang)

produces

# CONFIG_CC_IS_CLANG is not set

in all configs I'm building. (And it's by far not the only one. In
fact I've been carrying a patch which changes various such lines,
and as a result of your earlier reply I was intending to drop it.
Just that it didn't work as expected.)

> And isn't a dependency of another config?

This isn't supposed to matter for the presence/absence of said line
in the resulting .config. I'm not going to exclude though that the
current lack of any dependency in Xen is the reason for the
difference in behavior.

Jan

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