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: Masahiro Yamada <masahiroy@kernel.org>
Sometimes it is useful to preserve batches of configs when making
localmodconfig. For example, I usually don't want any usb and fs
modules to be disabled. Now we can do it by:
$ make LMC_KEEP="drivers/usb:fs" localmodconfig
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The code block surrounded by 'if' ... 'endif' is reduced into if_stmt,
which is accepted in the 'choice' context. Therefore, you can write any
statements within a choice block by wrapping 'if y' ... 'end'.
For example, you can create a menu inside a choice, like follows:
---------------->8----------------
choice
prompt "choice"
config A
bool "A"
config B
bool "B"
if y
menu "strange menu"
config C
bool "C"
endmenu
endif
endchoice
---------------->8----------------
I want to change such a weird structure into a syntax error.
In fact, the USB gadget Kconfig had used nested 'choice' for no good
reason until commit df8df5e4bc ("usb: get rid of 'choice' for
legacy gadget drivers") killed it.
I think the 'source' inside 'choice' is on the fence. It is at least
gramatically sensible as long as the included file contains only
bool/tristate configs. However, it makes the code unreadable, and people
tend to forget the fact that the file is included from the choice
block. Commit 10e5e6c249 ("usb: gadget: move choice ... endchoice to
legacy/Kconfig") got rid of the only usecase.
Going forward, you can only use 'config', 'comment', and 'if' inside
'choice'. This also recursively applies to 'if' blocks inside 'choice'.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Nesting choice statements does not make any sense.
Commit df8df5e4bc ("usb: get rid of 'choice' for legacy gadget
drivers") got rid of the only usecase.
I will turn it into a syntax error. Remove the test in advance.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The simple assignment is enough because memset() three lines above
has zero-cleared the structure.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The items described on those TODOs are already solved. So,
remove the comments.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
At least on my tests (building against Qt5.13), it seems to
me that, since Kernel 3.14, the split view mode is broken.
Maybe it was not a top priority during the conversion time.
Anyway, this patch changes the logic in order to properly
support the split view mode and the single view mode.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The port to Qt5 tried to preserve the same way as it used
to work with Qt3 and Qt4. However, at least with newer
versions of Qt5 (5.13), this doesn't work properly.
Change the schema by adding a vertical layout, in order
for it to start working properly again.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Both main config window and the item window have "Option"
name. That sounds weird, and makes harder to debug issues
of a window appearing at the wrong place.
So, change the title to reflect the contents of each
window.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The recommended way to initialize a null string is with
QString(). This is there at least since Qt5.5, with is
when qconf was ported to Qt5.
Fix those warnings:
scripts/kconfig/qconf.cc: In member function ‘void ConfigItem::updateMenu()’:
scripts/kconfig/qconf.cc:158:31: warning: ‘QString::null’ is deprecated: use QString() [-Wdeprecated-declarations]
158 | setText(noColIdx, QString::null);
| ^~~~
In file included from /usr/include/qt5/QtCore/qobject.h:47,
from /usr/include/qt5/QtWidgets/qwidget.h:45,
from /usr/include/qt5/QtWidgets/qmainwindow.h:44,
from /usr/include/qt5/QtWidgets/QMainWindow:1,
from scripts/kconfig/qconf.cc:9:
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Pull SPDX updates from Greg KH:
"Here are three SPDX patches for 5.7-rc1.
One fixes up the SPDX tag for a single driver, while the other two go
through the tree and add SPDX tags for all of the .gitignore files as
needed.
Nothing too complex, but you will get a merge conflict with your
current tree, that should be trivial to handle (one file modified by
two things, one file deleted.)
All three of these have been in linux-next for a while, with no
reported issues other than the merge conflict"
* tag 'spdx-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx:
ASoC: MT6660: make spdxcheck.py happy
.gitignore: add SPDX License Identifier
.gitignore: remove too obvious comments
If this file were compiled with -Wall, the following warning would be
reported:
scripts/kconfig/qconf.cc:312:6: warning: unused variable ‘i’ [-Wunused-variable]
int i;
^
The commit prepares to turn on -Wall for C++ host programs.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Some .gitignore files have comments like "Generated files",
"Ignore generated files" at the header part, but they are
too obvious.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The 'imply' statement may create unmet direct dependency when the
implied symbol depends on m.
[Test Code]
config FOO
tristate "foo"
imply BAZ
config BAZ
tristate "baz"
depends on BAR
config BAR
def_tristate m
config MODULES
def_bool y
option modules
If you set FOO=y, BAZ is also promoted to y, which results in the
following .config file:
CONFIG_FOO=y
CONFIG_BAZ=y
CONFIG_BAR=m
CONFIG_MODULES=y
This does not meet the dependency 'BAZ depends on BAR'.
Unlike 'select', what is worse, Kconfig never shows the
'WARNING: unmet direct dependencies detected for ...' for this case.
Because 'imply' is considered to be weaker than 'depends on', Kconfig
should take the direct dependency into account.
For clarification, describe this case in kconfig-language.rst too.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
The 'imply' keyword restricts a symbol to y or n, excluding m
when it is implied by y. This is the original behavior since
commit 237e3ad0f1 ("Kconfig: Introduce the "imply" keyword").
However, the author of this feature, Nicolas Pitre, stated that
the 'imply' keyword should not impose any restrictions.
(https://lkml.org/lkml/2020/2/19/714)
I agree, and want to get rid of this tricky behavior.
Suggested-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
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: Masahiro Yamada <masahiroy@kernel.org>
Since commit 89b9060987 ("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: 89b9060987 ("kconfig: Add yes2modconfig and mod2yesconfig targets.")
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
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 <masahiroy@kernel.org>
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: 3b9a19e089 ("kconfig: loop as long as we changed some symbols in randconfig")
Reported-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
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()
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 <bgolaszewski@baylibre.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
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: Thomas Hebb <tommyhebb@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Masahiro Yamada
Changbin Du
Mauro Carvalho Chehab
Linus Torvalds
Tetsuo Handa
Bartosz Golaszewski
Thomas Hebb