1. 29 5月, 2018 1 次提交
    • M
      kconfig: reference environment variables directly and remove 'option env=' · 104daea1
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      104daea1
  2. 28 5月, 2018 1 次提交
  3. 26 3月, 2018 2 次提交
    • E
      kconfig: Print reverse dependencies in groups · d9119b59
      Eugeniu Rosca 提交于
      Surprisingly or not, disabling a CONFIG option (which is assumed to
      be unneeded) may be not so trivial. Especially it is not trivial, when
      this CONFIG option is selected by a dozen of other configs. Before the
      moment commit 1ccb2714 ("kconfig: make "Selected by:" and
      "Implied by:" readable") popped up in v4.16-rc1, it was an absolute pain
      to break down the "Selected by" reverse dependency expression in order
      to identify all those configs which select (IOW *do not allow
      disabling*) a certain feature (assumed to be not needed).
      
      This patch tries to make one step further by putting at users'
      fingertips the revdep top level OR sub-expressions grouped/clustered by
      the tristate value they evaluate to. This should allow the users to
      directly concentrate on and tackle the _active_ reverse dependencies.
      
      To give some numbers and quantify the complexity of certain reverse
      dependencies, assuming commit 617aebe6 ("Merge tag
      'usercopy-v4.16-rc1' of
      git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux"), ARCH=arm64
      and vanilla arm64 defconfig, here is the top 10 CONFIG options with
      the highest amount of top level "||" sub-expressions/tokens that make
      up the final "Selected by" reverse dependency expression.
      
      | Config            | All revdep | Active revdep |
      |-------------------|------------|---------------|
      | REGMAP_I2C        | 212        | 9             |
      | CRC32             | 167        | 25            |
      | FW_LOADER         | 128        | 5             |
      | MFD_CORE          | 124        | 9             |
      | FB_CFB_IMAGEBLIT  | 114        | 2             |
      | FB_CFB_COPYAREA   | 111        | 2             |
      | FB_CFB_FILLRECT   | 110        | 2             |
      | SND_PCM           | 103        | 2             |
      | CRYPTO_HASH       | 87         | 19            |
      | WATCHDOG_CORE     | 86         | 6             |
      
      The story behind the above is that users need to visually
      review/evaluate 212 expressions which *potentially* select REGMAP_I2C
      in order to identify the expressions which *actually* select REGMAP_I2C,
      for a particular ARCH and for a particular defconfig used.
      
      To make this experience smoother, change the way reverse dependencies
      are displayed to the user from [1] to [2].
      
      [1] Old representation of DMA_ENGINE_RAID:
        Selected by:
        - AMCC_PPC440SPE_ADMA [=n] && DMADEVICES [=y] && (440SPe || 440SP)
        - BCM_SBA_RAID [=m] && DMADEVICES [=y] && (ARM64 [=y] || ...
        - FSL_RAID [=n] && DMADEVICES [=y] && FSL_SOC && ...
        - INTEL_IOATDMA [=n] && DMADEVICES [=y] && PCI [=y] && X86_64
        - MV_XOR [=n] && DMADEVICES [=y] && (PLAT_ORION || ARCH_MVEBU [=y] ...
        - MV_XOR_V2 [=y] && DMADEVICES [=y] && ARM64 [=y]
        - XGENE_DMA [=n] && DMADEVICES [=y] && (ARCH_XGENE [=y] || ...
        - DMATEST [=n] && DMADEVICES [=y] && DMA_ENGINE [=y]
      
      [2] New representation of DMA_ENGINE_RAID:
        Selected by [y]:
        - MV_XOR_V2 [=y] && DMADEVICES [=y] && ARM64 [=y]
        Selected by [m]:
        - BCM_SBA_RAID [=m] && DMADEVICES [=y] && (ARM64 [=y] || ...
        Selected by [n]:
        - AMCC_PPC440SPE_ADMA [=n] && DMADEVICES [=y] && (440SPe || ...
        - FSL_RAID [=n] && DMADEVICES [=y] && FSL_SOC && ...
        - INTEL_IOATDMA [=n] && DMADEVICES [=y] && PCI [=y] && X86_64
        - MV_XOR [=n] && DMADEVICES [=y] && (PLAT_ORION || ARCH_MVEBU [=y] ...
        - XGENE_DMA [=n] && DMADEVICES [=y] && (ARCH_XGENE [=y] || ...
        - DMATEST [=n] && DMADEVICES [=y] && DMA_ENGINE [=y]
      Suggested-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
      Reviewed-by: NPetr Vorel <pvorel@suse.cz>
      Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      d9119b59
    • M
      kconfig: clean-up reverse dependency help implementation · 9a47ceec
      Masahiro Yamada 提交于
      This commit splits out the special E_OR handling ('-' instead of '||')
      into a dedicated helper expr_print_revdev().
      
      Restore the original expr_print() prior to commit 1ccb2714
      ("kconfig: make "Selected by:" and "Implied by:" readable").
      
      This makes sense because:
      
        - We need to chop those expressions only when printing the reverse
          dependency, and only when E_OR is encountered
      
        - Otherwise, it should be printed as before, so fall back to
          expr_print()
      
      This also improves the behavior; for a single line, it was previously
      displayed in the same line as "Selected by", like this:
      
        Selected by: A [=n] && B [=n]
      
      This will be displayed in a new line, consistently:
      
        Selected by:
        - A [=n] && B [=n]
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NPetr Vorel <pvorel@suse.cz>
      9a47ceec
  4. 02 3月, 2018 1 次提交
    • M
      kconfig: set SYMBOL_AUTO to the symbol marked with defconfig_list · f4bc1eef
      Masahiro Yamada 提交于
      The 'defconfig_list' is a weird attribute.  If the '.config' is
      missing, conf_read_simple() iterates over all visible defaults,
      then it uses the first one for which fopen() succeeds.
      
      config DEFCONFIG_LIST
      	string
      	depends on !UML
      	option defconfig_list
      	default "/lib/modules/$UNAME_RELEASE/.config"
      	default "/etc/kernel-config"
      	default "/boot/config-$UNAME_RELEASE"
      	default "$ARCH_DEFCONFIG"
      	default "arch/$ARCH/defconfig"
      
      However, like other symbols, the first visible default is always
      written out to the .config file.  This might be different from what
      has been actually used.
      
      For example, on my machine, the third one "/boot/config-$UNAME_RELEASE"
      is opened, like follows:
      
        $ rm .config
        $ make oldconfig 2>/dev/null
        scripts/kconfig/conf  --oldconfig Kconfig
        #
        # using defaults found in /boot/config-4.4.0-112-generic
        #
        *
        * Restart config...
        *
        *
        * IRQ subsystem
        *
        Expose irq internals in debugfs (GENERIC_IRQ_DEBUGFS) [N/y/?] (NEW)
      
      However, the resulted .config file contains the first one since it is
      visible:
      
        $ grep CONFIG_DEFCONFIG_LIST .config
        CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
      
      In order to stop confusing people, prevent this CONFIG option from
      being written to the .config file.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      f4bc1eef
  5. 25 1月, 2018 1 次提交
    • P
      kconfig: make "Selected by:" and "Implied by:" readable · 1ccb2714
      Petr Vorel 提交于
      Reverse dependency expressions can get rather unwieldy, especially if
      a symbol is selected by more than a handful of other symbols. I.e. it's
      possible to have near endless expressions like:
         A && B && !C || D || F && (G || H) || [...]
      
      Chop these expressions into actually readable chunks:
         - A && B && !C
         - D
         - F && (G || H)
         - [...]
      
      I.e. transform the top level OR tokens into newlines and prepend each
      line with a minus. This makes the "Selected by:" and "Implied by:" blurb
      much easier to read. This is done only if there is more than one top
      level OR. "Depends on:" and "Range :" were deliberately left as they are.
      
      Based on idea from Paul Bolle.
      Suggested-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NPetr Vorel <petr.vorel@gmail.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      1ccb2714
  6. 22 1月, 2018 2 次提交
  7. 21 1月, 2018 7 次提交
  8. 15 12月, 2017 3 次提交
    • U
      kconfig: Clean up modules handling and fix crash · f77850d3
      Ulf Magnusson 提交于
      Kconfig currently doesn't handle 'm' appearing in a Kconfig file before
      the modules symbol is defined (the symbol with 'option modules'). The
      problem is the following code, which runs during parsing:
      
      	/* change 'm' into 'm' && MODULES */
      	if (e->left.sym == &symbol_mod)
      		return expr_alloc_and(e, expr_alloc_symbol(modules_sym));
      
      If the modules symbol has not yet been defined, modules_sym is NULL,
      giving an invalid expression.
      
      Here is a test file where both BEFORE_1 and BEFORE_2 trigger a segfault.
      If the modules symbol is removed, all symbols trigger segfaults.
      
      	config BEFORE_1
      		def_tristate y if m
      
      	if m
      	config BEFORE_2
      		def_tristate y
      	endif
      
      	config MODULES
      		def_bool y
      		option modules
      
      	config AFTER_1
      		def_tristate y if m
      
      	if m
      	config AFTER_2
      		def_tristate y
      	endif
      
      Fix the issue by rewriting 'm' in menu_finalize() instead. This function
      runs after parsing and is the proper place to do it. The following
      existing code in conf_parse() in zconf.y ensures that the modules symbol
      exists at that point:
      
      	if (!modules_sym)
      		modules_sym = sym_find( "n" );
      
      	...
      
      	menu_finalize(&rootmenu);
      
      The following tests were done to ensure no functional changes for
      configurations that don't reference 'm' before the modules symbol:
      
      	- zconfdump(stdout) was run with ARCH=x86 and ARCH=arm before
      	  and after the change and verified to produce identical output.
      	  This function prints all symbols, choices, and menus together
      	  with their properties and their dependency expressions. A
      	  rewritten 'm' appears as 'm && MODULES'.
      
      	  A small annoyance is that the assert(len != 0) in xfwrite()
      	  needs to be disabled in order to use zconfdump(), because it
      	  chokes on e.g. 'default ""'.
      
      	- The Kconfiglib test suite was run to indirectly verify that
      	  alldefconfig, allyesconfig, allnoconfig, and all defconfigs in
      	  the kernel still generate the same final .config.
      
      	- Valgrind was used to check for memory errors and (new) memory
      	  leaks.
      Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      f77850d3
    • U
      kconfig: Clarify expression rewriting · fa8cedae
      Ulf Magnusson 提交于
      menu_finalize() is one of the more opaque parts of Kconfig, and I need
      to make some changes to it to fix an issue related to modules. Add some
      comments related to expression rewriting and dependency propagation as a
      review aid. They will also help other people trying to understand the
      code.
      Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      fa8cedae
    • U
      kconfig: Rename menu_check_dep() to rewrite_m() · 9a826842
      Ulf Magnusson 提交于
      More directly describes the only thing it does.
      Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      9a826842
  9. 07 12月, 2017 1 次提交
    • U
      kconfig: Warn if choice default is not in choice · 2c37e084
      Ulf Magnusson 提交于
      This will catch mistakes like in the following real-world example, where
      a "CONFIG_" prefix snuck in, making an undefined symbol the default:
      
      	choice
      		prompt "Compiler optimization level"
      		default CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE
      
      	config CC_OPTIMIZE_FOR_PERFORMANCE
      		...
      
      	config CC_OPTIMIZE_FOR_SIZE
      		...
      
      	endchoice
      
      This now prints the following warning:
      
      	init/Kconfig:1036:warning: choice default symbol 'CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE' is not contained in the choice
      
      Cases where the default symbol belongs to the wrong choice are also
      detected.
      
      (The mistake is harmless here: Since the default symbol is not visible,
      the choice falls back on using the first visible symbol as the default,
      which is CC_OPTIMIZE_FOR_PERFORMANCE, as intended.)
      
      Discovered while playing around with Kconfiglib
      (https://github.com/ulfalizer/Kconfiglib).
      Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      2c37e084
  10. 16 11月, 2016 1 次提交
    • N
      Kconfig: Introduce the "imply" keyword · 237e3ad0
      Nicolas Pitre 提交于
      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: NNicolas Pitre <nico@linaro.org>
      Acked-by: NRichard Cochran <richardcochran@gmail.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NJohn Stultz <john.stultz@linaro.org>
      Reviewed-by: NJosh 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.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      237e3ad0
  11. 05 1月, 2016 1 次提交
  12. 25 2月, 2015 1 次提交
  13. 28 11月, 2014 1 次提交
  14. 10 6月, 2014 1 次提交
  15. 08 4月, 2014 1 次提交
  16. 09 10月, 2013 3 次提交
  17. 05 9月, 2013 2 次提交
    • Y
      kconfig: do not allow more than one symbol to have 'option modules' · e0627813
      Yann E. MORIN 提交于
      Previously, it was possible to have more than one symbol with the
      'option modules' attached to them, although only the last one would
      in fact control tristates.
      
      Since this does not make much sense, only allow at most one symbol to
      control tristates.
      
      Note: it is still possible to have more than one symbol that control
      tristates, but indirectly:
      
          config MOD1
              bool "mod1"
              select MODULES
          config MOD2
              bool "mod2"
              select MODULES
          config MODULES
              bool
              option modules
      Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      e0627813
    • Y
      kconfig: do not special-case 'MODULES' symbol · 6902dccf
      Yann E. MORIN 提交于
      Currently, the 'MODULES' symbol is hard-coded to be the default symbol
      that enables/disables tristates, if no other symbol was declared with
      'option modules'.
      
      While this used to be needed for the Linux kernel, we now have an
      explicit 'option modules' attached to the 'MODULES' symbol (since
      cset 11097a03), so we no longer need to special-case it in the
      kconfig code.
      
      Furthermore, kconfig is extensively used out of the Linux kernel, and
      other projects may have another meaning for a symbol named 'MODULES'.
      
      This patch changes the way we enable/disable tristates: if a symbol was
      found with 'option modules' attached to it, then that symbol controls
      enabling tristates. Otherwise, tristates are disabled, even if a symbol
      named 'MODULES' exists.
      Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      6902dccf
  18. 19 6月, 2013 1 次提交
  19. 30 5月, 2013 1 次提交
    • D
      kconfig/menu.c: fix multiple references to expressions in menu_add_prop() · e983b7b1
      Dirk Gouders 提交于
      menu_add_prop() applies upper menus' visibilities to actual prompts
      by AND-ing the prompts visibilities with the upper menus ones.
      
      This creates a further reference to the menu's visibilities and when
      the expression reduction functions do their work, they may remove or
      modify expressions that have multiple references, thus causing
      unpredictable side-effects.
      
      The following example Kconfig constructs a case where this causes
      problems: a menu and a prompt which's visibilities depend on the same
      symbol.  When invoking mconf with this Kconfig and pressing "Z" we
      see a problem caused by a free'd expression still referenced by the
      menu's visibility:
      
      ------------------------------------------------------------------------
      mainmenu "Kconfig Testing Configuration"
      
      config VISIBLE
      	def_bool n
      
      config Placeholder
      	bool "Place holder"
      
      menu "Invisible"
      	visible if VISIBLE
      
      config TEST_VAR
      	bool "Test option" if VISIBLE
      
      endmenu
      ------------------------------------------------------------------------
      
      This patch fixes this problem by creating copies of the menu's
      visibility expressions before AND-ing them with the prompt's one.
      Signed-off-by: NDirk Gouders <dirk@gouders.net>
      [yann.morin.1998@free.fr: move variable into its block-scope,
                                keep lines <80 chars, typo]
      Tested-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      Reviewed-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      e983b7b1
  20. 07 5月, 2013 1 次提交
  21. 01 5月, 2013 1 次提交
  22. 20 11月, 2012 1 次提交
  23. 25 10月, 2012 1 次提交
  24. 28 9月, 2012 2 次提交
  25. 08 8月, 2011 2 次提交