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

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

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?
Did you test with "def_bool" as the sole item in the config entry?
And isn't a dependency of another config?

Thanks,

-- 
Anthony PERARD

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