| Message ID | 20191212182740.2190199-7-anthony.perard@citrix.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | xen: Kconfig update with few extra | expand |
On 12/12/2019 18:27, Anthony PERARD wrote: > Now that Kconfig has the capability to run shell command when > generating CONFIG_* we can use it in some cases to test CFLAGS. > > CONFIG_INDIRECT_THUNK is a good example that wants to exist both in > Makefile and as a C macro, which Kconfig do. So use Kconfig to > generate CONFIG_INDIRECT_THUNK and have the CFLAGS depends on that. > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
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. 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 config INDIRECT_THUNK def_bool y if $(cc-option,-mindirect-branch-register) Jan
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. Maybe I should read to doc about the difference between "def_bool n" and "def_bool y if n", but there is probably no difference. > config INDIRECT_THUNK > def_bool y if $(cc-option,-mindirect-branch-register) Thanks,
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. Oh, then all is fine here. I guess they made this work more nicely in recent Kconfig - my comment above was based on observations in the past. Jan
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
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,
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
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 02bb05f42ef1..ac0fbe3e1aa1 100644 --- 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) + menu "Architecture Features" source "arch/Kconfig" diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 92fdbe9d6822..a2c257fb95b2 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -71,11 +71,9 @@ CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE endif # Compile with thunk-extern, indirect-branch-register if avaiable. -ifneq ($(call cc-option,$(CC),-mindirect-branch-register,n),n) +ifeq ($(CONFIG_INDIRECT_THUNK),y) CFLAGS += -mindirect-branch=thunk-extern -mindirect-branch-register -CFLAGS += -DCONFIG_INDIRECT_THUNK CFLAGS += -fno-jump-tables -export CONFIG_INDIRECT_THUNK=y endif # If supported by the compiler, reduce stack alignment to 8 bytes. But allow
Now that Kconfig has the capability to run shell command when generating CONFIG_* we can use it in some cases to test CFLAGS. CONFIG_INDIRECT_THUNK is a good example that wants to exist both in Makefile and as a C macro, which Kconfig do. So use Kconfig to generate CONFIG_INDIRECT_THUNK and have the CFLAGS depends on that. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- xen/arch/x86/Kconfig | 3 +++ xen/arch/x86/Rules.mk | 4 +--- 2 files changed, 4 insertions(+), 3 deletions(-)