Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 25 5月, 2020 1 次提交
    • M
      kconfig: announce removal of 'kvmconfig' and 'xenconfig' shorthands · bcfefb61
      由 Masahiro Yamada 提交于 
      kvmconfig' is a shorthand for kvm_guest.config to save 7 character typing.

xenconfig' is a shorthand for xen.config to save 1 character typing.

There is nothing more than that.

There are more files in kernel/configs/, so it is not maintainable
to wire-up every config fragment to the Kconfig Makefile. Hence,
we should not do this at all.

These will be removed after Linux 5.10. Meanwhile, the following
warning message will be displayed if they are used.

WARNING: 'make kvmconfig' will be removed after Linux 5.10
         Please use 'make kvm_guest.config' instead.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      bcfefb61
  3. 13 5月, 2020 1 次提交
  5. 12 5月, 2020 4 次提交
  7. 08 4月, 2020 6 次提交
  9. 29 3月, 2020 1 次提交
  11. 25 3月, 2020 2 次提交
  13. 13 3月, 2020 2 次提交
  15. 03 3月, 2020 1 次提交
    • M
      kbuild: use KBUILD_DEFCONFIG as the fallback for DEFCONFIG_LIST · 2a86f661
      由 Masahiro Yamada 提交于 
      Most of the Kconfig commands (except defconfig and all*config) read
the .config file as a base set of CONFIG options.

When it does not exist, the files in DEFCONFIG_LIST are searched in
this order and loaded if found.

I do not see much sense in the last two lines in DEFCONFIG_LIST.

[1] ARCH_DEFCONFIG

The entry for DEFCONFIG_LIST is guarded by 'depends on !UML'. So, the
ARCH_DEFCONFIG definition in arch/x86/um/Kconfig is meaningless.

arch/{sh,sparc,x86}/Kconfig define ARCH_DEFCONFIG depending on 32 or
64 bit variant symbols. This is a little bit strange; ARCH_DEFCONFIG
should be a fixed string because the base config file is loaded before
the symbol evaluation stage.

Using KBUILD_DEFCONFIG makes more sense because it is fixed before
Kconfig is invoked. Fortunately, arch/{sh,sparc,x86}/Makefile define it
in the same way, and it works as expected. Hence, replace ARCH_DEFCONFIG
with "arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)".

[2] arch/$(ARCH)/defconfig

This file path is no longer valid. The defconfig files are always located
in the arch configs/ directories.

  $ find arch -name defconfig | sort
  arch/alpha/configs/defconfig
  arch/arm64/configs/defconfig
  arch/csky/configs/defconfig
  arch/nds32/configs/defconfig
  arch/riscv/configs/defconfig
  arch/s390/configs/defconfig
  arch/unicore32/configs/defconfig

The path arch/*/configs/defconfig is already covered by
"arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)". So, this file path is
not necessary.

I moved the default KBUILD_DEFCONFIG to the top Makefile. Otherwise,
the 7 architectures listed above would end up with endless loop of
syncconfig.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      2a86f661
  17. 05 2月, 2020 1 次提交
  19. 04 2月, 2020 2 次提交
    • M
      kbuild: rename hostprogs-y/always to hostprogs/always-y · 5f2fb52f
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <masahiroy@kernel.org>
      5f2fb52f
    • M
      kconfig: fix broken dependency in randconfig-generated .config · c8fb7d7e
      由 Masahiro Yamada 提交于 
      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: 3b9a19e0 ("kconfig: loop as long as we changed some symbols in randconfig")
Reported-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      c8fb7d7e
  21. 10 1月, 2020 1 次提交
    • B
      kconfig: fix an "implicit declaration of function" warning · ba82f52e
      由 Bartosz Golaszewski 提交于 
      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: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      ba82f52e
  23. 07 1月, 2020 17 次提交
    • T
      kconfig: fix nesting of symbol help text · a9609686
      由 Thomas Hebb 提交于 
      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] && <choice>

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] && <choice>
Signed-off-by: NThomas Hebb <tommyhebb@gmail.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      a9609686
    • T
      kconfig: distinguish between dependencies and visibility in help text · 3460d0bc
      由 Thomas Hebb 提交于 
      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 bcdedcc1 ("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 bcdedcc1, 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: NThomas Hebb <tommyhebb@gmail.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      3460d0bc
    • T
      kconfig: list all definitions of a symbol in help text · edda15f2
      由 Thomas Hebb 提交于 
      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 bcdedcc1 ("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-bcdedcc1 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]
   <snip>
   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 bcdedcc1: 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: NThomas Hebb <tommyhebb@gmail.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      edda15f2
    • T
      kconfig: Add yes2modconfig and mod2yesconfig targets. · 89b90609
      由 Tetsuo Handa 提交于 
      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: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      89b90609
    • M
      kconfig: use $(PERL) in Makefile · c8138a57
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <masahiroy@kernel.org>
      c8138a57
    • M
      kconfig: fix too deep indentation in Makefile · 1d135237
      由 Masahiro Yamada 提交于 
      The indentation for if ... else ... fi is too deep. Fix it.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      1d135237
    • M
      kconfig: localmodconfig: fix indentation for closing brace · 68f0d627
      由 Masahiro Yamada 提交于 
      This is the closing brace for the foreach loop. Fix the misleading
indentation.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      68f0d627
    • M
      kconfig: localmodconfig: remove unused $config · 5edcef84
      由 Masahiro Yamada 提交于 
      This is unused since commit cdfc4795 ("kconfig: search for a config
to base the local(mod|yes)config on").

Having unused $config is confusing because $config is used as a local
variable in various sub-routines.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      5edcef84
    • M
      kconfig: squash prop_alloc() into menu_add_prop() · adf7c5bd
      由 Masahiro Yamada 提交于 
      prop_alloc() is only called from menu_add_prop(). Squash it.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      adf7c5bd
    • M
      kconfig: remove sym from struct property · 6397d96b
      由 Masahiro Yamada 提交于 
      struct property can reference to the symbol that it is associated with
by prop->menu->sym.

Fix up the one usage of prop->sym, and remove sym from struct property.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      6397d96b
    • M
      kconfig: remove 'prompt' argument from menu_add_prop() · 2ffeef61
      由 Masahiro Yamada 提交于 
      This function no longer uses the 'prompt' argument.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      2ffeef61
    • M
      kconfig: move prompt handling to menu_add_prompt() from menu_add_prop() · 024352ff
      由 Masahiro Yamada 提交于 
      menu_add_prompt() is the only function that calls menu_add_prop() with
non-NULL prompt.

So, the code inside the if-conditional block of menu_add_prop() can be
moved to menu_add_prompt().
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      024352ff
    • M
      kconfig: remove 'prompt' symbol · 1be6e791
      由 Masahiro Yamada 提交于 
      Now that 'prompt' is only reduced from T_WORD_QUOTE without any action,
use T_WORD_QUOTE directly.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      1be6e791
    • M
      kconfig: drop T_WORD from the RHS of 'prompt' symbol · 801b27db
      由 Masahiro Yamada 提交于 
      Commit 8636a1f9 ("treewide: surround Kconfig file paths with double
quotes") killed use-cases to reduce an unquoted string into the 'prompt'
symbol.

Kconfig still allows to use an unquoted string in the context of menu,
source, or prompt.

So, you can omit quoting if the prompt is a single word:

    bool foo

..., but I do not think this is so useful.

Let's require quoting:

    bool "foo"

All the Kconfig files in the kernel are written in this way.

Remove the T_WORD from the right-hand side of the symbol 'prompt'.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      801b27db
    • M
      kconfig: use parent->dep as the parentdep of 'menu' · de026ca9
      由 Masahiro Yamada 提交于 
      In menu_finalize(), the dependency of a menu entry is propagated
downwards.

For the 'menu', parent->dep and parent->prompt->visible.expr have
the same expression. Both accumulate the 'depends on' of itself and
upper menu entries.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      de026ca9
    • M
      kconfig: remove the rootmenu check in menu_add_prop() · f64048a2
      由 Masahiro Yamada 提交于 
      This reverts commit ba6ff60d ("kconfig: don't emit warning upon
rootmenu's prompt redefinition").

At that time, rootmenu.prompt was always set first, then it was set
again if a "mainmenu" statement was specified in the Kconfig file.

This is no longer the case since commit 0724a7c3 ("kconfig: Don't
leak main menus during parsing"). Remove the unneeded check.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      f64048a2
    • M
      kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf · 8b41fc44
      由 Masahiro Yamada 提交于 
      Commit bc081dd6 ("kbuild: generate modules.builtin") added
infrastructure to generate modules.builtin, the list of all
builtin modules.

Basically, it works like this:

  - Kconfig generates include/config/tristate.conf, the list of
    tristate CONFIG options with a value in a capital letter.

  - scripts/Makefile.modbuiltin makes Kbuild descend into
    directories to collect the information of builtin modules.

I am not a big fan of it because Kbuild ends up with traversing
the source tree twice.

I am not sure how perfectly it should work, but this approach cannot
avoid false positives; even if the relevant CONFIG option is tristate,
some Makefiles forces obj-m to obj-y.

Some examples are:

  arch/powerpc/platforms/powermac/Makefile:
    obj-$(CONFIG_NVRAM:m=y)         += nvram.o

  net/ipv6/Makefile:
    obj-$(subst m,y,$(CONFIG_IPV6)) += inet6_hashtables.o

  net/netlabel/Makefile:
    obj-$(subst m,y,$(CONFIG_IPV6)) += netlabel_calipso.o

Nobody has complained about (or noticed) it, so it is probably fine to
have false positives in modules.builtin.

This commit simplifies the implementation. Let's exploit the fact
that every module has MODULE_LICENSE(). (modpost shows a warning if
MODULE_LICENSE is missing. If so, 0-day bot would already have blocked
such a module.)

I added MODULE_FILE to <linux/module.h>. When the code is being compiled
as builtin, it will be filled with the file path of the module, and
collected into modules.builtin.info. Then, scripts/link-vmlinux.sh
extracts the list of builtin modules out of it.

This new approach fixes the false-positives above, but adds another
type of false-positives; non-modular code may have MODULE_LICENSE()
by mistake. This is not a big deal, it is just the code is always
orphan. We can clean it up if we like. You can see cleanup examples by:

  $ git log --grep='make.* explicitly non-modular'

To sum up, this commits deletes lots of code, but still produces almost
equivalent results. Please note it does not increase the vmlinux size at
all. As you can see in include/asm-generic/vmlinux.lds.h, the .modinfo
section is discarded in the link stage.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      8b41fc44
  25. 17 12月, 2019 1 次提交