Commit Graph

88 Commits

Author SHA1 Message Date
Masahiro Yamada d41809ff7a kconfig: add 'static' to some file-local data
Fix some warnings from sparce like follows:

  warning: symbol '...' was not declared. Should it be static?

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-08-14 13:30:04 +09:00
Masahiro Yamada cfc6eea9f6 kconfig: do not use OR-assignment for zero-cleared structure
The simple assignment is enough because memset() three lines above
has zero-cleared the structure.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-05-12 13:28:30 +09:00
Masahiro Yamada 3a9dd3ecb2 kconfig: make 'imply' obey the direct dependency
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>
2020-03-13 10:05:34 +09:00
Masahiro Yamada def2fbffe6 kconfig: allow symbols implied by y to become m
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>
2020-03-13 10:05:34 +09:00
Masahiro Yamada adf7c5bd06 kconfig: squash prop_alloc() into menu_add_prop()
prop_alloc() is only called from menu_add_prop(). Squash it.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-01-07 02:18:44 +09:00
Masahiro Yamada 6397d96ba5 kconfig: remove sym from struct property
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: Masahiro Yamada <masahiroy@kernel.org>
2020-01-07 02:18:44 +09:00
Linus Torvalds 106f1466e7 Kconfig updates for v5.3
- always require argument for --defconfig and remove the hard-coded
   arch/$(ARCH)/defconfig path
 
 - make arch/$(SRCARCH)/configs/defconfig the new default of defconfig
 
 - some code cleanups
 -----BEGIN PGP SIGNATURE-----
 
 iQJSBAABCgA8FiEEbmPs18K1szRHjPqEPYsBB53g2wYFAl0oxR0eHHlhbWFkYS5t
 YXNhaGlyb0Bzb2Npb25leHQuY29tAAoJED2LAQed4NsG6mcP/20IEEaWCnpQf45c
 0f724ZiVJzl3auhAyZZzjHSj6n4J0cP+91BSilS9tfkCcrhemxK6JitTbLdNq6qi
 pRAVX3cGxeAn0qpqRqGwcDGL9I+iEi559fSG4k0/tWP1ILDvNFKy6dEvPqzPXdRX
 uRCt99Mw52GInKAnXMtoK6CbOQjDjzw/iuvn6+MgDRdVpTI4wzMMUPY5PdEC6ebH
 xnGzVzNT1PlSyW8FsHSUNkpYDWtRAfqapFWzv1zUS9s0PLkCgHNq/M1uZKFfxrl7
 GRZPGZvlDUTTnoED0uGWun+GAA78dr5GUWPC0Dm5oUMZs0dkcPnafaNl7jt+mHkf
 akbHHMxLqmSC7JAodBaCbwmqFr1vQamQgpwWD2EEA5ixOU26MIXFH38aEcNCl9zt
 Ym310BIYvVWaqDqOHy1AHBQSSheuo76WdJMYKuQyaa85QUKvys51nMQTRgFuF/13
 UNdOpUk4bCM5eUHg5gQHT8E50biJ1p97qmv9iYMKjQ8PssG43vushGpSwROwNxEX
 BvOf3wjocL5I666dRWW/y7vhbwRrKraNYmEVdJ9v7YbEmDNbjcQkuwHTdKS8JYz2
 xrwrwio8xUKjSaIKZ3zilAQ5CE47JgWPn48OwL1HeDadrXTbSmIARpZRIFL8f4NR
 1vjhSc1Ll1kmopSnKJRmpMvKjMlb
 =1fr/
 -----END PGP SIGNATURE-----

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

Pull Kconfig updates from Masahiro Yamada:

 - always require argument for --defconfig and remove the hard-coded
   arch/$(ARCH)/defconfig path

 - make arch/$(SRCARCH)/configs/defconfig the new default of defconfig

 - some code cleanups

* tag 'kconfig-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
  kconfig: remove meaningless if-conditional in conf_read()
  kconfig: Fix spelling of sym_is_changable
  unicore32: rename unicore32_defconfig to defconfig
  kconfig: make arch/*/configs/defconfig the default of KBUILD_DEFCONFIG
  kconfig: add static qualifier to expand_string()
  kconfig: require the argument of --defconfig
  kconfig: remove always false ifeq ($(KBUILD_DEFCONFIG,) conditional
2019-07-12 16:06:27 -07:00
Marco Ammon baa23ec860 kconfig: Fix spelling of sym_is_changable
There is a spelling mistake in "changable", it is corrected to
"changeable" and all call sites are updated accordingly.

Signed-off-by: Marco Ammon <marco.ammon@fau.de>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-06 21:58:23 +09:00
Mauro Carvalho Chehab cd238effef docs: kbuild: convert docs to ReST and rename to *.rst
The kbuild documentation clearly shows that the documents
there are written at different times: some use markdown,
some use their own peculiar logic to split sections.

Convert everything to ReST without affecting too much
the author's style and avoiding adding uneeded markups.

The conversion is actually:
  - add blank lines and identation in order to identify paragraphs;
  - fix tables markups;
  - add some lists markups;
  - mark literal blocks;
  - adjust title markups.

At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.

Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-06-14 14:21:21 -06:00
Masahiro Yamada 558e78e3ce kconfig: split some C files out of zconf.y
I want to compile each C file independently instead of including all
of them from zconf.y.

Split out confdata.c, expr.c, symbol.c, and preprocess.c .
These are low-hanging fruits.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-28 22:22:38 +09:00
Masahiro Yamada 0c87410010 kconfig: convert to SPDX License Identifier
All files in lxdialog/ are licensed under GPL-2.0+, and the rest are
under GPL-2.0. I added GPL-2.0 tags to test scripts in tests/.

Documentation/process/license-rules.rst does not suggest anything
about the flex/bison files. Because flex does not accept the C++
comment style at the very top of a file, I used the C style for
zconf.l, and so for zconf.y for consistency.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-28 22:22:28 +09:00
Masahiro Yamada 2aabbed677 kconfig: remove S_OTHER symbol type and correct dependency tracking
The S_OTHER type could be set only when conf_read_simple() is reading
include/config/auto.conf file.

For example, CONFIG_FOO=y exists in include/config/auto.conf but it is
missing from the currently parsed Kconfig files, sym_lookup() allocates
a new symbol, and sets its type to S_OTHER.

Strangely, it will be set to S_STRING by conf_set_sym_val() a few lines
below while it is obviously bool or tristate type. On the other hand,
when CONFIG_BAR="bar" is being dropped from include/config/auto.conf,
its type remains S_OTHER. Because for_all_symbols() omits S_OTHER
symbols, conf_touch_deps() misses to touch include/config/bar.h

This behavior has been a pretty mystery for me, and digging the git
histroy did not help. At least, touching depfiles is broken for string
type symbols.

I removed S_OTHER entirely, and reimplemented it more simply.

If CONFIG_FOO was visible in the previous syncconfig, but is missing
now, what we want to do is quite simple; just call conf_touch_dep()
to touch include/config/foo.h instead of allocating a new symbol data.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-08 10:42:41 +09:00
Masahiro Yamada f498926c47 kconfig: improve the recursive dependency report
This commit improves the messages of the recursive dependency.
Currently, sym->dir_dep.expr is not checked.  Hence, any dependency
in property visibility is regarded as the dependency of the symbol.

[Test Code 1]

  config A
          bool "a"
          depends on B

  config B
          bool "b"
          depends on A

[Test Code 2]

  config A
          bool "a" if B

  config B
          bool "b"
          depends on A

For both cases above, the same message is displayed:

        symbol B depends on A
        symbol A depends on B

This commit changes the message for the latter, like this:

        symbol B depends on A
        symbol A prompt is visible depending on B

Also, 'select' and 'imply' are distinguished.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Dirk Gouders <dirk@gouders.net>
2018-08-22 23:21:39 +09:00
Masahiro Yamada 5e8c5299d3 kconfig: report recursive dependency involving 'imply'
Currently, Kconfig does not complain about the recursive dependency
where 'imply' keywords are involved.

[Test Code]

  config A
          bool "a"

  config B
          bool "b"
          imply A
          depends on A

In the code above, Kconfig cannot calculate the symbol values correctly
due to the circular dependency.  For example, allyesconfig followed by
syncconfig results in an odd behavior because CONFIG_B becomes visible
in syncconfig.

  $ make allyesconfig
  scripts/kconfig/conf  --allyesconfig Kconfig
  #
  # configuration written to .config
  #
  $ cat .config
  #
  # Automatically generated file; DO NOT EDIT.
  # Main menu
  #
  CONFIG_A=y
  $ make syncconfig
  scripts/kconfig/conf  --syncconfig Kconfig
  *
  * Restart config...
  *
  *
  * Main menu
  *
  a (A) [Y/n/?] y
    b (B) [N/y/?] (NEW)

To detect this correctly, sym_check_expr_deps() should recurse to
not only sym->rev_dep.expr but also sym->implied.expr .

At this moment, sym_check_print_recursive() cannot distinguish
'select' and 'imply' since it does not know the precise context
where the recursive dependency has been hit.  This will be solved
by the next commit.

In fact, even the document and the unit-test are confused.  Using
'imply' does not solve recursive dependency since 'imply' addresses
the unmet direct dependency, which 'select' could cause.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Dirk Gouders <dirk@gouders.net>
2018-08-22 23:21:39 +09:00
Masahiro Yamada f1575595d1 kconfig: error out when seeing recursive dependency
Originally, recursive dependency was a fatal error for Kconfig
because Kconfig cannot compute symbol values in such a situation.

Commit d595cea624 ("kconfig: print more info when we see a recursive
dependency") changed it to a warning, which I guess was not intentional.

Get it back to an error again.

Also, rename the unit test directory "warn_recursive_dep" to
"err_recursive_dep" so that it matches to the behavior.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Dirk Gouders <dirk@gouders.net>
2018-08-22 23:21:38 +09:00
Masahiro Yamada 1880861226 kconfig: remove P_ENV property type
This property is not set by anyone since commit 104daea149 ("kconfig:
reference environment variables directly and remove 'option env='").

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
2018-08-14 09:01:47 +09:00
Masahiro Yamada c151272d16 kconfig: remove unused sym_get_env_prop() function
This function is unused since commit 104daea149 ("kconfig: reference
environment variables directly and remove 'option env='").

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
2018-08-14 08:59:57 +09:00
Dirk Gouders 693359f7ac kconfig: rename SYMBOL_AUTO to SYMBOL_NO_WRITE
Over time, the use of the flag SYMBOL_AUTO changed from initially
marking three automatically generated symbols ARCH, KERNELRELEASE and
UNAME_RELEASE to today's effect of protecting symbols from being
written out.

Currently, only symbols of type CHOICE and those with option
defconf_list set have that flag set.

Reflect that change in semantics in the flag's name.

Signed-off-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-18 01:18:09 +09:00
Masahiro Yamada 5b31a97467 kconfig: remove sym_expand_string_value()
There is no more caller of sym_expand_string_value().

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
2018-05-29 03:31:19 +09:00
Masahiro Yamada 104daea149 kconfig: reference environment variables directly and remove 'option env='
To get access to environment variables, Kconfig needs to define a
symbol using "option env=" syntax.  It is tedious to add a symbol entry
for each environment variable given that we need to define much more
such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
in Kconfig.

Adding '$' for symbol references is grammatically inconsistent.
Looking at the code, the symbols prefixed with 'S' are expanded by:
 - conf_expand_value()
   This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
 - sym_expand_string_value()
   This is used to expand strings in 'source' and 'mainmenu'

All of them are fixed values independent of user configuration.  So,
they can be changed into the direct expansion instead of symbols.

This change makes the code much cleaner.  The bounce symbols 'SRCARCH',
'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.

sym_init() hard-coding 'UNAME_RELEASE' is also gone.  'UNAME_RELEASE'
should be replaced with an environment variable.

ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
without '$' prefix.

The new syntax is addicted by Make.  The variable reference needs
parentheses, like $(FOO), but you can omit them for single-letter
variables, like $F.  Yet, in Makefiles, people tend to use the
parenthetical form for consistency / clarification.

At this moment, only the environment variable is supported, but I will
extend the concept of 'variable' later on.

The variables are expanded in the lexer so we can simplify the token
handling on the parser side.

For example, the following code works.

[Example code]

  config MY_TOOLCHAIN_LIST
          string
          default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"

[Result]

  $ make -s alldefconfig && tail -n 1 .config
  CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
2018-05-29 03:28:58 +09:00
Masahiro Yamada f8f69dc0b4 kconfig: make unmet dependency warnings readable
Currently, the unmet dependency warnings end up with endlessly long
expressions, most of which are false positives.

Here is test code to demonstrate how it currently works.

[Test Case]

  config DEP1
          def_bool y

  config DEP2
          bool "DEP2"

  config A
          bool "A"
          select E

  config B
          bool "B"
          depends on DEP2
          select E

  config C
          bool "C"
          depends on DEP1 && DEP2
          select E

  config D
          def_bool n
          select E

  config E
          bool
          depends on DEP1 && DEP2

[Result]

  $ make config
  scripts/kconfig/conf  --oldaskconfig Kconfig
  *
  * Linux Kernel Configuration
  *
  DEP2 (DEP2) [N/y/?] (NEW) n
  A (A) [N/y/?] (NEW) y
  warning: (A && B && D) selects E which has unmet direct
  dependencies (DEP1 && DEP2)

Here, I see some points to be improved.

First, '(A || B || D)' would make more sense than '(A && B && D)'.
I am not sure if this is intentional, but expr_simplify_unmet_dep()
turns OR expressions into AND, like follows:

        case E_OR:
                return expr_alloc_and(

Second, we see false positives.  'A' is a real unmet dependency.
'B' is false positive because 'DEP1' is fixed to 'y', and 'B' depends
on 'DEP2'.  'C' was correctly dropped by expr_simplify_unmet_dep().
'D' is also false positive because it has no chance to be enabled.
Current expr_simplify_unmet_dep() cannot avoid those false positives.

After all, I decided to use the same helpers as used for printing
reverse dependencies in the help.

With this commit, unreadable warnings (most of the reported symbols are
false positives) in the real world:

$ make ARCH=score allyesconfig
scripts/kconfig/conf  --allyesconfig Kconfig
warning: (HWSPINLOCK_QCOM && AHCI_MTK && STMMAC_PLATFORM &&
 DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_OXNAS && DWMAC_ROCKCHIP &&
 DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_GEMINI &&
 PINCTRL_OXNAS && PINCTRL_ROCKCHIP && PINCTRL_DOVE &&
 PINCTRL_ARMADA_37XX && PINCTRL_STM32 && S3C2410_WATCHDOG &&
 VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 &&
 LPC18XX_DMAMUX && VIDEO_OMAP4 && COMMON_CLK_GEMINI &&
 COMMON_CLK_ASPEED && COMMON_CLK_NXP && COMMON_CLK_OXNAS &&
 COMMON_CLK_BOSTON && QCOM_ADSP_PIL && QCOM_Q6V5_PIL && QCOM_GSBI &&
 ATMEL_EBI && ST_IRQCHIP && RESET_IMX7 && PHY_HI6220_USB &&
 PHY_RALINK_USB && PHY_ROCKCHIP_PCIE && PHY_DA8XX_USB) selects
 MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
warning: (PINCTRL_AT91 && PINCTRL_AT91PIO4 && PINCTRL_OXNAS &&
 PINCTRL_PISTACHIO && PINCTRL_PIC32 && PINCTRL_MESON &&
 PINCTRL_NOMADIK && PINCTRL_MTK && PINCTRL_MT7622 && GPIO_TB10X)
 selects OF_GPIO which has unmet direct dependencies (GPIOLIB && OF &&
 HAS_IOMEM)
warning: (FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && LOCKDEP)
 selects FRAME_POINTER which has unmet direct dependencies
 (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || SUPERH || BLACKFIN ||
 MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS)

will be turned into:

$ make ARCH=score allyesconfig
scripts/kconfig/conf  --allyesconfig Kconfig

WARNING: unmet direct dependencies detected for MFD_SYSCON
  Depends on [n]: HAS_IOMEM [=n]
  Selected by [y]:
  - PINCTRL_STM32 [=y] && PINCTRL [=y] && (ARCH_STM32 ||
 COMPILE_TEST [=y]) && OF [=y]
  - RTC_DRV_AT91SAM9 [=y] && RTC_CLASS [=y] && (ARCH_AT91 ||
 COMPILE_TEST [=y])
  - RESET_IMX7 [=y] && RESET_CONTROLLER [=y]
  - PHY_HI6220_USB [=y] && (ARCH_HISI && ARM64 ||
 COMPILE_TEST [=y])
  - PHY_RALINK_USB [=y] && (RALINK || COMPILE_TEST [=y])
  - PHY_ROCKCHIP_PCIE [=y] && (ARCH_ROCKCHIP && OF [=y] ||
 COMPILE_TEST [=y])

WARNING: unmet direct dependencies detected for OF_GPIO
  Depends on [n]: GPIOLIB [=y] && OF [=y] && HAS_IOMEM [=n]
  Selected by [y]:
  - PINCTRL_MTK [=y] && PINCTRL [=y] && (ARCH_MEDIATEK ||
 COMPILE_TEST [=y]) && OF [=y]
  - PINCTRL_MT7622 [=y] && PINCTRL [=y] && (ARCH_MEDIATEK ||
 COMPILE_TEST [=y]) && OF [=y] && (ARM64 || COMPILE_TEST [=y])

WARNING: unmet direct dependencies detected for FRAME_POINTER
  Depends on [n]: DEBUG_KERNEL [=y] && (CRIS || M68K || FRV || UML ||
 SUPERH || BLACKFIN || MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS [=n]
  Selected by [y]:
  - LATENCYTOP [=y] && DEBUG_KERNEL [=y] && STACKTRACE_SUPPORT [=y] &&
 PROC_FS [=y] && !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND &&
 !ARC && !X86

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Petr Vorel <petr.vorel@gmail.com>
2018-03-26 02:04:06 +09:00
Masahiro Yamada f622f82795 kconfig: warn unmet direct dependency of tristate symbols selected by y
Commit 246cf9c26b ("kbuild: Warn on selecting symbols with unmet
direct dependencies") forcibly promoted ->dir_dep.tri to yes from mod.
So, the unmet direct dependencies of tristate symbols are not reported.

[Test Case]

  config MODULES
          def_bool y
          option modules

  config A
          def_bool y
          select B

  config B
          tristate "B"
          depends on m

This causes unmet dependency because 'B' is forced 'y' ignoring
'depends on m'.  This should be warned.

On the other hand, the following case ('B' is bool) should not be
warned, so 'depends on m' for bool symbols should be naturally treated
as 'depends on y'.

[Test Case2 (not unmet dependency)]

  config MODULES
          def_bool y
          option modules

  config A
          def_bool y
          select B

  config B
          bool "B"
          depends on m

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26 02:04:05 +09:00
Ulf Magnusson f467c5640c kconfig: only write '# CONFIG_FOO is not set' for visible symbols
=== Background ===

 - Visible n-valued bool/tristate symbols generate a
   '# CONFIG_FOO is not set' line in the .config file. The idea is to
   remember the user selection without having to set a Makefile
   variable. Having n correspond to the variable being undefined in the
   Makefiles makes for easy CONFIG_* tests.

 - Invisible n-valued bool/tristate symbols normally do not generate a
   '# CONFIG_FOO is not set' line, because user values from .config
   files have no effect on invisible symbols anyway.

Currently, there is one exception to this rule: Any bool/tristate symbol
that gets the value n through a 'default' property generates a
'# CONFIG_FOO is not set' line, even if the symbol is invisible.

Note that this only applies to explicitly given defaults, and not when
the symbol implicitly defaults to n (like bool/tristate symbols without
'default' properties do).

This is inconsistent, and seems redundant:

  - As mentioned, the '# CONFIG_FOO is not set' won't affect the symbol
    once the .config is read back in.

  - Even if the symbol is invisible at first but becomes visible later,
    there shouldn't be any harm in recalculating the default value
    rather than viewing the '# CONFIG_FOO is not set' as a previous
    user value of n.

=== Changes ===

Change sym_calc_value() to only set SYMBOL_WRITE (write to .config) for
non-n-valued 'default' properties.

Note that SYMBOL_WRITE is always set for visible symbols regardless of whether
they have 'default' properties or not, so this change only affects invisible
symbols.

This reduces the size of the x86 .config on my system by about 1% (due
to removed '# CONFIG_FOO is not set' entries).

One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:

	config FOO
		bool

	config FOO
		bool
		default n

With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.

This change only affects generated .config files and not autoconf.h:
autoconf.h only includes #defines for non-n bool/tristate symbols.

=== Testing ===

The following testing was done with the x86 Kconfigs:

 - .config files generated before and after the change were compared to
   verify that the only difference is some '# CONFIG_FOO is not set'
   entries disappearing. A couple of these were inspected manually, and
   most turned out to be from redundant 'default n/def_bool n'
   properties.

 - The generated include/generated/autoconf.h was compared before and
   after the change and verified to be identical.

 - As a sanity check, the same modification was done to Kconfiglib.
   The Kconfiglib test suite was then run to check for any mismatches
   against the output of the C implementation.

Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26 02:03:58 +09:00
Masahiro Yamada cd81fc82b9 kconfig: add xstrdup() helper
We already have xmalloc(), xcalloc(), and xrealloc(().  Add xstrdup()
as well to save tedious error handling.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-02 00:26:47 +09:00
Masahiro Yamada 523ca58b7d kconfig: remove const qualifier from sym_expand_string_value()
This function returns realloc'ed memory, so the returned pointer
must be passed to free() when done.  So, 'const' qualifier is odd.
It is allowed to modify the expanded string.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-02-10 11:31:49 +09:00
Masahiro Yamada d717f24d8c kconfig: add xrealloc() helper
We already have xmalloc(), xcalloc().  Add xrealloc() as well
to save tedious error handling.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-02-10 11:26:04 +09:00
Masahiro Yamada 9e3e10c725 kconfig: send error messages to stderr
These messages should be directed to stderr.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-02-09 04:10:10 +09:00
Masahiro Yamada cb67ab2cd2 kconfig: do not write choice values when their dependency becomes n
"# CONFIG_... is not set" for choice values are wrongly written into
the .config file if they are once visible, then become invisible later.

  Test case
  ---------

---------------------------(Kconfig)----------------------------
config A
	bool "A"

choice
	prompt "Choice ?"
	depends on A

config CHOICE_B
	bool "Choice B"

config CHOICE_C
	bool "Choice C"

endchoice
----------------------------------------------------------------

---------------------------(.config)----------------------------
CONFIG_A=y
----------------------------------------------------------------

With the Kconfig and .config above,

  $ make config
  scripts/kconfig/conf  --oldaskconfig Kconfig
  *
  * Linux Kernel Configuration
  *
  A (A) [Y/n] n
  #
  # configuration written to .config
  #
  $ cat .config
  #
  # Automatically generated file; DO NOT EDIT.
  # Linux Kernel Configuration
  #
  # CONFIG_A is not set
  # CONFIG_CHOICE_B is not set
  # CONFIG_CHOICE_C is not set

Here,

  # CONFIG_CHOICE_B is not set
  # CONFIG_CHOICE_C is not set

should not be written into the .config file because their dependency
"depends on A" is unmet.

Currently, there is no code that clears SYMBOL_WRITE of choice values.

Clear SYMBOL_WRITE for all symbols in sym_calc_value(), then set it
again after calculating visibility.  To simplify the logic, set the
flag if they have non-n visibility, regardless of types, and regardless
of whether they are choice values or not.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-02-09 04:08:05 +09:00
Masahiro Yamada b92d804a51 kconfig: drop 'boolean' keyword
No more users of this keyword.  Drop it according to the notice by
commit 6341e62b21 ("kconfig: use bool instead of boolean for type
definition attributes").

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
2018-01-22 00:49:29 +09:00
Ulf Magnusson 24161a6711 kconfig: Don't leak 'source' filenames during parsing
The 'source_stmt' nonterminal takes a 'prompt', which consists of either
a T_WORD or a T_WORD_QUOTE, both of which are always allocated on the
heap in zconf.l and need to have their associated strings freed. Free
them.

The existing code already makes sure to always copy the string, but add
a warning to sym_expand_string_value() to make it clear that the string
must be copied, just in case.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 387,504 bytes in 15,545 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 344,616 bytes in 14,355 blocks
	   ...

Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 01:14:01 +09:00
Masahiro Yamada e3b03bf29d kconfig: display recursive dependency resolution hint just once
Commit 1c199f2878 ("kbuild: document recursive dependency limitation
/ resolution") probably intended to show a hint along with "recursive
dependency detected!" error, but it missed to add {...} guard, and the
hint is displayed in every loop of the dep_stack traverse, annoyingly.

This error was detected by GCC's -Wmisleading-indentation when switching
to build-time generation of lexer/parser.

scripts/kconfig/symbol.c: In function ‘sym_check_print_recursive’:
scripts/kconfig/symbol.c:1150:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
   if (stack->sym == last_sym)
   ^~
scripts/kconfig/symbol.c:1153:4: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
    fprintf(stderr, "For a resolution refer to Documentation/kbuild/kconfig-language.txt\n");
    ^~~~~~~

I could simply add {...} to surround the three fprintf(), but I rather
chose to move the hint after the loop to make the whole message readable.

Fixes: 1c199f2878 ("kbuild: document recursive dependency limitation / resolution"
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
2017-12-16 11:12:53 +09:00
Heinrich Schuchardt 88127dae6e kconfig/symbol.c: use correct pointer type argument for sizeof
sym_arr is of type struct symbol **.
So in malloc we need sizeof(struct symbol *).

The problem was indicated by coccinelle.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-11-23 23:12:02 +09:00
Nicolas Pitre 237e3ad0f1 Kconfig: Introduce the "imply" keyword
The "imply" keyword is a weak version of "select" where the target
config symbol can still be turned off, avoiding those pitfalls that come
with the "select" keyword.

This is useful e.g. with multiple drivers that want to indicate their
ability to hook into a secondary subsystem while allowing the user to
configure that subsystem out without also having to unset these drivers.

Currently, the same effect can almost be achieved with:

config DRIVER_A
	tristate

config DRIVER_B
	tristate

config DRIVER_C
	tristate

config DRIVER_D
	tristate

[...]

config SUBSYSTEM_X
	tristate
	default DRIVER_A || DRIVER_B || DRIVER_C || DRIVER_D || [...]

This is unwieldy to maintain especially with a large number of drivers.
Furthermore, there is no easy way to restrict the choice for SUBSYSTEM_X
to y or n, excluding m, when some drivers are built-in. The "select"
keyword allows for excluding m, but it excludes n as well. Hence
this "imply" keyword.  The above becomes:

config DRIVER_A
	tristate
	imply SUBSYSTEM_X

config DRIVER_B
	tristate
	imply SUBSYSTEM_X

[...]

config SUBSYSTEM_X
	tristate

This is much cleaner, and way more flexible than "select". SUBSYSTEM_X
can still be configured out, and it can be set as a module when none of
the drivers are configured in or all of them are modular.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Cc: Paul Bolle <pebolle@tiscali.nl>
Cc: linux-kbuild@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: Michal Marek <mmarek@suse.com>
Cc: Edward Cree <ecree@solarflare.com>
Link: http://lkml.kernel.org/r/1478841010-28605-2-git-send-email-nicolas.pitre@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-11-16 09:26:33 +01:00
Dirk Gouders fa64e5f6a3 kconfig/symbol.c: handle choice_values that depend on 'm' symbols
If choices consist of choice_values of type tristate that depend on
symbols set to 'm', those choice_values are not set to 'n' if the
choice is changed from 'm' to 'y' (in which case only one active
choice_value is allowed). Those values are also written to the config
file causing modules to be built when they should not.

The following config can be used to reproduce and examine the problem;
with the frontend of your choice set "Choice 0" and "Choice 1" to 'm',
then set "Tristate Choice" to 'y' and save the configuration:

config modules
	boolean modules
	default y
	option modules

config dependency
	tristate "Dependency"
	default m

choice
	prompt "Tristate Choice"
	default choice0

config choice0
	tristate "Choice 0"

config choice1
	tristate "Choice 1"
	depends on dependency

endchoice

This patch sets tristate choice_values' visibility that depend on
symbols set to 'm' to 'n' if the corresponding choice is set to 'y'.

This makes them disappear from the choice list and will also cause the
choice_values' value set to 'n' in sym_calc_value() and as a result
they are written as "not set" to the resulting .config file.

Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Gouders <dirk@gouders.net>
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
2016-05-10 21:14:27 +02:00
Luis R. Rodriguez 1c199f2878 kbuild: document recursive dependency limitation / resolution
Recursive dependency issues with kconfig are unavoidable due to
some limitations with kconfig, since these issues are recurring
provide a hint to the user how they can resolve these dependency
issues and also document why such limitation exists.

While at it also document a bit of future prospects of ways to
enhance Kconfig, including providing formal semantics and evaluation
of use of a SAT solver. If you're interested in this work or prospects
of it check out the kconfig-sat project wiki [0] and mailing list [1].

[0] http://kernelnewbies.org/KernelProjects/kconfig-sat
[1] https://groups.google.com/d/forum/kconfig-sat

Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: James Bottomley <jbottomley@odin.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Paul Bolle <pebolle@tiscali.nl>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Mate Soos <soos.mate@gmail.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
2015-10-08 15:36:16 +02:00
Markus Elfring 35ffd08d9b kconfig: Delete unnecessary checks before the function call "sym_calc_value"
The sym_calc_value() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Michal Marek <mmarek@suse.com>
2015-08-19 16:41:02 +02:00
Jan Beulich 31847b67be kconfig: allow use of relations other than (in)equality
Over the years I found it desirable to be able to use all sorts of
relations, not just (in)equality. And apparently I'm not the only one,
as there's at least one example in the tree where the programmer
assumed this would work (see DEBUG_UART_8250_WORD in
arch/arm/Kconfig.debug). Another possible use would e.g. be to fold the
two SMP/NR_CPUS prompts into one: SMP could be promptless, simply
depending on NR_CPUS > 1.

A (desirable) side effect of this change - resulting from numeric
values now necessarily being compared as numbers rather than as
strings - is that comparing hex values now works as expected: Other
than int ones (which aren't allowed to have leading zeroes), zeroes
following the 0x prefix made them compare unequal even if their values
were equal.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
2015-06-15 14:05:58 +02:00
Michal Marek ad8d40cda3 kconfig: Remove unnecessary prototypes from headers
Signed-off-by: Michal Marek <mmarek@suse.cz>
2015-02-25 15:00:17 +01:00
Martin Walch 8d9dfe8276 kconfig: fix trivial typos and update mconf documentation
This fixes lots of typos in comments and strings.

It also updates the documentation strings in mconf to reflect the changes in
the user interface from the two commits

6364fd0cb1
  menuconfig: Add Save/Load buttons
1bdbac478a
  menuconfig: Get rid of the top-level entries for "Load an Alternate/Save an Alternate"

And it updates the layout of the example search result, i. e. moves down the
"Defined at" and "Depends on" lines and adds a symbol state ([=n]) to the
symbol in the "Selected by" line.

Furthermore, the help texts now should fit in 80 columns again when viewed
in mconf.

Signed-off-by: Martin Walch <walch.martin@web.de>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2013-10-08 23:52:14 +02:00
Kees Cook 129784abc9 kconfig: switch to "long long" for sanity
Instead of using "long" for kconfig "hex" and "range" values, which may
change in size depending on the host architecture, use "long long". This
will allow values greater than INT_MAX on 32-bit hosts when cross
compiling.

Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2013-08-15 22:48:06 +02:00
Yann E. MORIN 508382a042 kconfig: simplify symbol-search code
There is no need for a double indirection in the temporary array that
stores the internediate search results.

Reported-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
2013-07-16 20:39:42 +02:00
Yann E. MORIN 1407f97aed kconfig: don't allocate n+1 elements in temporary array
The temporary array that stores the search results is not NULL-terminated,
so there is no reason to allocate n+1 elements.

Reported-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
2013-07-16 20:36:18 +02:00
Yann E. MORIN 803b351988 kconfig: minor style fixes in symbol-search code
Two minor style fixes:
  - no space before/after parenthesis in function definition
  - no {} for single-line if()

And one grammar fix in a comment.

Reported-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
2013-07-16 20:34:44 +02:00
Yann E. MORIN 26e933e3c3 kconfig: avoid multiple calls to strlen
Calls to strlen are costly, so avoid calling strln as much as we can.

Reported-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
2013-07-16 20:26:46 +02:00
Kees Cook b57caaaed2 kconfig: allow "hex" and "range" to support longs
The parsing routines for Kconfig files use strtol(), but store and
render values as int. Switch types and formating to long to support a
wider range of values. For example, 0x80000000 wasn't representable.

Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2013-06-29 15:30:17 +02:00
Yann E. MORIN 193b40aeb5 kconfig: sort found symbols by relevance
When searching for symbols, return the symbols sorted by relevance.

Sorting is done as thus:
  - first, symbols that match exactly
  - then, alphabetical sort

Since the search can be a regexp, it is possible that more than one symbol
matches exactly. In this case, we can't decide which to sort first, so we
fallback to alphabeticall sort.

Explain this (new!) sorting heuristic in the documentation.

Reported-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jean Delvare <jdelvare@suse.de>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Roland Eggner <edvx1@systemanalysen.net>
Cc: Wang YanQing <udknight@gmail.com>

--
Changes v1->v2:
  - drop the previous, complex heuristic in favour of a simpler heuristic
    that is both easier to understand, *and* to maintain (Jean)
  - explain sorting heuristic in the doc  (Jean)
2013-06-24 19:57:45 +02:00
Arve Hjønnevåg fbe98bb9ed kconfig: Fix defconfig when one choice menu selects options that another choice menu depends on
The defconfig and Kconfig combination below, which is based on 3.10-rc4
Kconfigs, resulted in several options getting set to "m" instead of "y".

defconfig.choice:
---8<---
CONFIG_MODULES=y
CONFIG_USB_ZERO=y
---8<---

Kconfig.choice:
---8<---
menuconfig MODULES
	bool "Enable loadable module support"

config CONFIGFS_FS
	tristate "Userspace-driven configuration filesystem"

config OCFS2_FS
        tristate "OCFS2 file system support"
        depends on CONFIGFS_FS
        select CRC32

config USB_LIBCOMPOSITE
	tristate
	select CONFIGFS_FS

choice
	tristate "USB Gadget Drivers"
	default USB_ETH

config USB_ZERO
	tristate "Gadget Zero (DEVELOPMENT)"
	select USB_LIBCOMPOSITE

config USB_ETH
	tristate "Ethernet Gadget (with CDC Ethernet support)"
	select USB_LIBCOMPOSITE

endchoice

config CRC32
        tristate "CRC32/CRC32c functions"
        default y

choice
        prompt "CRC32 implementation"
        depends on CRC32
        default CRC32_SLICEBY8

config CRC32_SLICEBY8
        bool "Slice by 8 bytes"

endchoice
---8<---

$ scripts/kconfig/conf --defconfig=defconfig.choice Kconfig.choice

would result in:

.config:
---8<---
CONFIG_MODULES=y
CONFIG_CONFIGFS_FS=m
CONFIG_USB_LIBCOMPOSITE=m
CONFIG_USB_ZERO=m
CONFIG_CRC32=y
CONFIG_CRC32_SLICEBY8=y
---8<---

when the expected result would be:

.config:
---8<---
CONFIG_MODULES=y
CONFIG_CONFIGFS_FS=y
CONFIG_USB_LIBCOMPOSITE=y
CONFIG_USB_ZERO=y
CONFIG_CRC32=y
CONFIG_CRC32_SLICEBY8=y
---8<---

Signed-off-by: Arve Hjønnevåg <arve@android.com>
[yann.morin.1998@free.fr: add the resulting .config to commit log,
                          remove unneeded USB_GADGET from the defconfig]
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2013-06-16 11:00:30 +02:00
Alan Cox 177acf7846 kconfig: Fix malloc handling in conf tools
(and get them out of the noise in the audit work)

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
2012-11-20 12:12:47 +01:00
Arnaud Lacombe 5d09598d48 kconfig: fix new choices being skipped upon config update
Running `oldconfig' after any of the following configuration change:

either trivial addition, such as:

config A
	bool "A"

choice
	prompt "Choice ?"
	depends on A

	config CHOICE_B
		bool "Choice B"

	config CHOICE_C
		bool "Choice C"
endchoice

or more tricky change:

OLD KCONFIG                      |  NEW KCONFIG
                                 |
                                 |  config A
                                 |          bool "A"
                                 |
choice                           |  choice
        prompt "Choice ?"        |          prompt "Choice ?"
                                 |
        config CHOICE_C          |          config CHOICE_C
                bool "Choice C"  |                  bool "Choice C"
                                 |
        config CHOICE_D          |          config CHOICE_D
                bool "Choice D"  |                  bool "Choice D"
endchoice                        |
                                 |          config CHOICE_E
                                 |                  bool "Choice E"
                                 |                  depends on A
                                 |  endchoice

will not cause the choice to be considered as NEW, and thus not be
asked. The cause of this behavior is that choice's novelty are computed
statically right after the saved configuration has been read. At this
point, the new dependency's value is still unknown and asserted to be
`no'. Moreover, no update to this decision is made afterward.

Correct this by dynamically evaluating a choice's novelty, and removing the
static evaluation.

Reported-and-tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
2012-01-26 11:01:56 +01:00
Arnaud Lacombe e54e692ba6 kconfig: introduce specialized printer
Make conf_write_symbol() grammar agnostic to be able to use it from different
code path. These path pass a printer callback which will print a symbol's name
and its value in different format.

conf_write_symbol()'s job become mostly only to prepare a string for the
printer. This avoid to have to pass specialized flag to generic
functions

Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
[mmarek: rebased on top of de12518 (kconfig: autogenerated config_is_xxx
macro)]
Signed-off-by: Michal Marek <mmarek@suse.cz>
2011-07-01 16:23:27 +02:00