linux/scripts/kconfig, branch v5.6

kconfig: Invalidate all symbols after changing to y or m.

2020-02-05T04:45:37Z

Since commit 89b9060987d9 ("kconfig: Add yes2modconfig and mod2yesconfig targets.") forgot to clear SYMBOL_VALID bit after changing to y or m, these targets did not save the changes. Call sym_clear_all_valid() so that all symbols are revalidated. Fixes: 89b9060987d9 ("kconfig: Add yes2modconfig and mod2yesconfig targets.") Signed-off-by: Tetsuo Handa Signed-off-by: Masahiro Yamada

kbuild: rename hostprogs-y/always to hostprogs/always-y

2020-02-03T16:53:07Z

In old days, the "host-progs" syntax was used for specifying host programs. It was renamed to the current "hostprogs-y" in 2004. It is typically useful in scripts/Makefile because it allows Kbuild to selectively compile host programs based on the kernel configuration. This commit renames like follows: always -> always-y hostprogs-y -> hostprogs So, scripts/Makefile will look like this: always-$(CONFIG_BUILD_BIN2C) += ... always-$(CONFIG_KALLSYMS) += ... ... hostprogs := $(always-y) $(always-m) I think this makes more sense because a host program is always a host program, irrespective of the kernel configuration. We want to specify which ones to compile by CONFIG options, so always-y will be handier. The "always", "hostprogs-y", "hostprogs-m" will be kept for backward compatibility for a while. Signed-off-by: Masahiro Yamada

kconfig: fix broken dependency in randconfig-generated .config

2020-02-03T16:49:12Z

Running randconfig on arm64 using KCONFIG_SEED=0x40C5E904 (e.g. on v5.5) produces the .config with CONFIG_EFI=y and CONFIG_CPU_BIG_ENDIAN=y, which does not meet the !CONFIG_CPU_BIG_ENDIAN dependency. This is because the user choice for CONFIG_CPU_LITTLE_ENDIAN vs CONFIG_CPU_BIG_ENDIAN is set by randomize_choice_values() after the value of CONFIG_EFI is calculated. When this happens, the has_changed flag should be set. Currently, it takes the result from the last iteration. It should accumulate all the results of the loop. Fixes: 3b9a19e08960 ("kconfig: loop as long as we changed some symbols in randconfig") Reported-by: Vincenzo Frascino Signed-off-by: Masahiro Yamada

Merge tag 'kconfig-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

2020-02-01T18:25:55Z

Pull Kconfig updates from Masahiro Yamada: - add 'yes2modconfig' and 'mod2yesconfig' targets (useful mainly for turning syzbot configs into more modular ones as a step to minimizing the result) - sanitize help text - various code cleanups * tag 'kconfig-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kconfig: fix documentation typos kconfig: fix an "implicit declaration of function" warning kconfig: fix nesting of symbol help text kconfig: distinguish between dependencies and visibility in help text kconfig: list all definitions of a symbol in help text kconfig: Add yes2modconfig and mod2yesconfig targets. kconfig: use $(PERL) in Makefile kconfig: fix too deep indentation in Makefile kconfig: localmodconfig: fix indentation for closing brace kconfig: localmodconfig: remove unused $config kconfig: squash prop_alloc() into menu_add_prop() kconfig: remove sym from struct property kconfig: remove 'prompt' argument from menu_add_prop() kconfig: move prompt handling to menu_add_prompt() from menu_add_prop() kconfig: remove 'prompt' symbol kconfig: drop T_WORD from the RHS of 'prompt' symbol kconfig: use parent->dep as the parentdep of 'menu' kconfig: remove the rootmenu check in menu_add_prop()

kconfig: fix an "implicit declaration of function" warning

2020-01-09T17:44:54Z

strncasecmp() & strcasecmp() functions are declared in strings.h, not string.h. On most environments the former is implicitly included by the latter but on some setups, building menuconfig results in the following warning: HOSTCC scripts/kconfig/mconf.o scripts/kconfig/mconf.c: In function ‘search_conf’: scripts/kconfig/mconf.c:423:6: warning: implicit declaration of function ‘strncasecmp’ [-Wimplicit-function-declaration] if (strncasecmp(dialog_input_result, CONFIG_, strlen(CONFIG_)) == 0) ^~~~~~~~~~~ scripts/kconfig/mconf.c: In function ‘main’: scripts/kconfig/mconf.c:1021:8: warning: implicit declaration of function ‘strcasecmp’ [-Wimplicit-function-declaration] if (!strcasecmp(mode, "single_menu")) ^~~~~~~~~~ Fix it by explicitly including strings.h. Signed-off-by: Bartosz Golaszewski Signed-off-by: Masahiro Yamada

kconfig: fix nesting of symbol help text

2020-01-06T17:18:45Z

When we generate the help text of a symbol (e.g. when a user presses '?' in menuconfig), we do two things: 1. We iterate through every prompt that belongs to that symbol, printing its text and its location in the menu tree. 2. We print symbol-wide information that's not linked to a particular prompt, such as what it selects/is selected by and what it implies/is implied by. Each prompt we print for 1 starts with a line that's not indented indicating where the prompt is defined, then continues with indented lines that describe properties of that particular definition. Once we get to 2, however, we print all the global data indented as well! Visually, this makes it look like the symbol-wide data is associated with the last prompt we happened to print rather than the symbol as a whole. Fix this by removing the indentation for symbol-wide information. Before: Symbol: CPU_FREQ [=n] Type : bool Defined at drivers/cpufreq/Kconfig:4 Prompt: CPU Frequency scaling Location: -> CPU Power Management -> CPU Frequency scaling Selects: SRCU [=n] Selected by [n]: - ARCH_SA1100 [=n] && After: Symbol: CPU_FREQ [=n] Type : bool Defined at drivers/cpufreq/Kconfig:4 Prompt: CPU Frequency scaling Location: -> CPU Power Management -> CPU Frequency scaling Selects: SRCU [=n] Selected by [n]: - ARCH_SA1100 [=n] && Signed-off-by: Thomas Hebb Signed-off-by: Masahiro Yamada

kconfig: distinguish between dependencies and visibility in help text

2020-01-06T17:18:45Z

Kconfig makes a distinction between dependencies (defined by "depends on" expressions and enclosing "if" blocks) and visibility (which includes all dependencies, but also includes inline "if" expressions of individual properties as well as, for prompts, "visible if" expressions of enclosing menus). Before commit bcdedcc1afd6 ("menuconfig: print more info for symbol without prompts"), the "Depends on" lines of a symbol's help text indicated the visibility of the prompt property they appeared under. After bcdedcc1afd, there was always only a single "Depends on" line, which indicated the visibility of the first P_SYMBOL property of the symbol. Since P_SYMBOLs never have inline if expressions, this was in effect the same as the dependencies of the menu item that the P_SYMBOL was attached to. Neither of these situations accurately conveyed the dependencies of a symbol--the first because it was actually the visibility, and the second because it only showed the dependencies from a single definition. With this series, we are back to printing separate dependencies for each definition, but we print the actual dependencies (rather than the visibility) in the "Depends on" line. However, it can still be useful to know the visibility of a prompt, so this patch adds a "Visible if" line that shows the visibility only if the visibility is different from the dependencies (which it isn't for most prompts in Linux). Before: Symbol: THUMB2_KERNEL [=n] Type : bool Defined at arch/arm/Kconfig:1417 Prompt: Compile the kernel in Thumb-2 mode Depends on: (CPU_V7 [=y] || CPU_V7M [=n]) && !CPU_V6 [=n] && !CPU_V6K [=n] Location: -> Kernel Features Selects: ARM_UNWIND [=n] After: Symbol: THUMB2_KERNEL [=n] Type : bool Defined at arch/arm/Kconfig:1417 Prompt: Compile the kernel in Thumb-2 mode Depends on: (CPU_V7 [=y] || CPU_V7M [=n]) && !CPU_V6 [=n] && !CPU_V6K [=n] Visible if: (CPU_V7 [=y] || CPU_V7M [=n]) && !CPU_V6 [=n] && !CPU_V6K [=n] && !CPU_THUMBONLY [=n] Location: -> Kernel Features Selects: ARM_UNWIND [=n] Signed-off-by: Thomas Hebb Signed-off-by: Masahiro Yamada

kconfig: list all definitions of a symbol in help text

2020-01-06T17:18:45Z

In Kconfig, each symbol (representing a config option) can be defined in multiple places. Each definition may or may not have a prompt, which allows the option to be set via an interface like menuconfig. Each definition has a set of dependencies, which determine whether its prompt is visible and whether other pieces of the definition, like a default value, take effect. Historically, a symbol's help text (i.e. what's shown when a user presses '?' in menuconfig) contained some symbol-wide information not tied to any particular definition (e.g. what other symbols it selects) as well as the location (file name and line number) and dependencies of each prompt. Notably, the help text did not show the location or dependencies of definitions without prompts. Because this made it hard to reason about symbols that had no prompts, commit bcdedcc1afd6 ("menuconfig: print more info for symbol without prompts") changed the help text so that, instead of containing the location and dependencies of each prompt, it contained the location and dependencies of the symbol's first definition, regardless of whether or not that definition had a prompt. For symbols with only one definition, that change makes sense. However, it breaks down for symbols with multiple definitions: each definition has its own set of dependencies (the `dep` field of `struct menu`), and those dependencies are ORed together to get the symbol's dependency list (the `dir_dep` field of `struct symbol`). By printing only the dependencies of the first definition, the help text misleads users into believing that an option is more narrowly-applicable than it actually is. For an extreme example of this, we can look at the SYS_TEXT_BASE symbol in the Das U-Boot project (version 2019.10), which also uses Kconfig. (I unfortunately could not find an illustrative example in Linux.) This config option specifies the load address of the built binary and, as such, is applicable to basically every configuration possible. And yet, without this patch, its help text is as follows: Symbol: SYS_TEXT_BASE [=] Type : hex Prompt: U-Boot base address Location: -> ARM architecture Prompt: Text Base Location: -> Boot images Defined at arch/arm/mach-aspeed/Kconfig:9 Depends on: ARM [=n] && ARCH_ASPEED [=n] The help text indicates that the option is applicable only for a specific unselected architecture (aspeed), because that architecture's promptless definition (which just sets a default value), happens to be the first one seen. No definition or dependency information is printed for either of the two prompts listed. Because source locations and dependencies are fundamentally properties of definitions and not of symbols, we should treat them as such. This patch brings back the pre-bcdedcc1afd6 behavior for definitions with prompts but also separately prints the location and dependencies of those without prompts, solving the original problem in a different way. With this change, our SYS_TEXT_BASE example becomes Symbol: SYS_TEXT_BASE [=] Type : hex Defined at arch/arm/mach-stm32mp/Kconfig:83 Prompt: U-Boot base address Depends on: ARM [=n] && ARCH_STM32MP [=n] Location: -> ARM architecture Defined at Kconfig:532 Prompt: Text Base Depends on: !NIOS2 [=n] && !XTENSA [=n] && !EFI_APP [=n] Location: -> Boot images Defined at arch/arm/mach-aspeed/Kconfig:9 Depends on: ARM [=n] && ARCH_ASPEED [=n] Defined at arch/arm/mach-socfpga/Kconfig:25 Depends on: ARM [=n] && ARCH_SOCFPGA [=n] Defined at board/sifive/fu540/Kconfig:15 Depends on: RISCV [=n] && TARGET_SIFIVE_FU540 [=n] which is a much more accurate representation. Note that there is one notable difference between what gets printed for prompts after this change and what got printed before bcdedcc1afd6: the "Depends on" line now accurately represents the prompt's dependencies instead of conflating those with the prompt's visibility (which can include extra conditions). See the patch later in this series titled "kconfig: distinguish between dependencies and visibility in help text" for more details and better handling of that nuance. Signed-off-by: Thomas Hebb Signed-off-by: Masahiro Yamada

kconfig: Add yes2modconfig and mod2yesconfig targets.

2020-01-06T17:18:45Z

Since kernel configs provided by syzbot are close to "make allyesconfig", it takes long time to rebuild. This is especially waste of time when we need to rebuild for many times (e.g. doing manual printk() inspection, bisect operations). We can save time if we can exclude modules which are irrelevant to each problem. But "make localmodconfig" cannot exclude modules which are built into vmlinux because /sbin/lsmod output is used as the source of modules. Therefore, this patch adds "make yes2modconfig" which converts from =y to =m if possible. After confirming that the interested problem is still reproducible, we can try "make localmodconfig" (and/or manually tune based on "Modules linked in:" line) in order to exclude modules which are irrelevant to the interested problem. While we are at it, this patch also adds "make mod2yesconfig" which converts from =m to =y in case someone wants to convert from =m to =y after "make localmodconfig". Signed-off-by: Tetsuo Handa Cc: Dmitry Vyukov Signed-off-by: Masahiro Yamada

kconfig: use $(PERL) in Makefile

2020-01-06T17:18:45Z

The top Makefile defines and exports the variable 'PERL'. Use it in case somebody wants to specify a particular version of perl from the command line. Signed-off-by: Masahiro Yamada