Age | Commit message (Collapse) | Author |
|
Upstream is dropping support for is not set, so we adjust our
configs accordingly.
Commit:
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=for-next&id=55de8686df7ed2b5237867b130e30c728bbd9db4
kconfig: change .config format to use =n instead of "is not set"
The .config file uses "# CONFIG_FOO is not set" form to represent
disabled options. In the old days, it was useful because the .config
was directly included from Makefiles. For example, you can use
"ifdef CONFIG_FOO" in Makefiles to check if the option is enabled.
Commit c955ccafc38e ("kconfig: fix .config dependencies") introduced
include/config/auto.conf, which mirrors the .config, but trims down
all disabled options.
Since then, include/config/auto.conf defines CONFIG options during the
build. The .config is used just for storing the user's configuration.
I do not see a strong reason to use a particular pattern of comment
for disabled options.
With this commit, Kconfig will output disable options in a more natural
form, "CONFIG_FOO=n".
Kconfig accepts both "# CONFIG_FOO is not set" and "CONFIG_FOO=n" as a
valid input. You do not need to update arch/*/configs/*_defconfig files
for now. "git bisect" should be able to cross the commit in both ways
without any issue.
A problem may occur if you parse the .config for the "# ... is not set"
patterns.
I adjusted streamline_config.pl, merge_config.sh,
scripts/kconfig/tests/.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Boris Kolpackov <boris@codesynthesis.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Yann CARDAILLAC <ycnakajsph@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Fixes [YOCTO 6777] Unable to set CONFIG_COMPAT=y to kernel config
Add support for running 32 bit binaries to the x32 and x86_64 fragments.
This supports legacy software and is follows the recommendation in the
Kconfig help.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
MTRR is common enough it should just be included in the x86* cfg
fragments already included by these machines.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Move the basic arch, MSR, CPUID, and MICROCODE CONFIG options out of the
common-pc*-cpu.cfg fragments and into the cfg/x86*cfg fragments where
they can be more easily reused.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
These are the defaults for x86 and x86_64 when doing a defconfig
on those arch with the kernel.org tree. Ours might as well be
the same values.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
In mainline defconfigs we have:
arch/x86/configs/i386_defconfig:# CONFIG_MTRR_SANITIZER is not set
arch/x86/configs/x86_64_defconfig:# CONFIG_MTRR_SANITIZER is not set
But the defaults given by the Kconfig stanza are "def_bool y" so
if we want to match the defconfigs, we need to call it out as off
explicitly.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The default x86[64] defconfig on a kernel.org 3.4 tree will have these
enabled. Since we can't be sure we'll be running on a platform
with or without these issues, it makes sense for us to have them
enabled here as well.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
There will be a significant amount of cfg data that is common
across all x86 BSPs. Make a landing ground for it here, similar
to what ARM has, so that we don't duplicate a bunch of stuff
in every x86 BSP file.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|