1. 25 6月, 2013 1 次提交
    • Y
      kconfig: loop as long as we changed some symbols in randconfig · 3b9a19e0
      Yann E. MORIN 提交于
      Because of choice-in-a-choice constructs, it can happen that not all
      symbols are assigned a value during randconfig, leading in rare cases
      to this situation:
      
          ---8<--- choice-in-choice.in
          choice
              bool "A/B/C"
          config A
              bool "A"
      
          config B
              bool "B"
          if B
          choice
              bool "E/F"
          config E
              bool "E"
          config F
              bool "F"
          endchoice
          endif # B
      
          config C
              bool "C"
          endchoice
          ---8<---
      
          $ ./scripts/kconfig/conf --randconfig choice-in-choice.in
          [--SNIP--]
          $ ./scripts/kconfig/conf --silentoldconfig choice-in-choice.in </dev/null
          [--SNIP--]
          A/B/C
            1. A (A)
          > 2. B (B)
            3. C (C)
          choice[1-3]: 2
            E/F
            > 1. E (E) (NEW)
              2. F (F) (NEW)
            choice[1-2]: aborted!
      
          Console input/output is redirected. Run 'make oldconfig' to update
          configuration.
      
      Fix this by looping in randconfig for as long as some symbol gets assigned
      a value.
      
      Note: this was spotted with the USB EHCI Debug Device Gadget (USB_G_DBGP),
      which uses this choice-in-a-choice construct, and exhibits this problem.
      The example above is just a stripped-down minimalist test-case.
      Signed-off-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      3b9a19e0
  2. 16 6月, 2013 1 次提交
    • A
      kconfig: Fix defconfig when one choice menu selects options that another choice menu depends on · fbe98bb9
      Arve Hjønnevåg 提交于
      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: NArve 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: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      Reviewed-by: N"Yann E. MORIN" <yann.morin.1998@free.fr>
      Signed-off-by: NYann E. MORIN <yann.morin.1998@free.fr>
      fbe98bb9
  3. 20 11月, 2012 3 次提交
  4. 15 1月, 2012 1 次提交
  5. 02 7月, 2011 2 次提交
  6. 01 7月, 2011 1 次提交
    • A
      kconfig: introduce specialized printer · e54e692b
      Arnaud Lacombe 提交于
      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: NArnaud Lacombe <lacombar@gmail.com>
      [mmarek: rebased on top of de125187 (kconfig: autogenerated config_is_xxx
      macro)]
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      e54e692b
  7. 10 6月, 2011 1 次提交
  8. 07 6月, 2011 1 次提交
  9. 15 12月, 2010 2 次提交
  10. 22 11月, 2010 1 次提交
  11. 20 9月, 2010 3 次提交
  12. 13 8月, 2010 2 次提交
  13. 03 8月, 2010 2 次提交
    • S
      kconfig: add savedefconfig · 7cf3d73b
      Sam Ravnborg 提交于
      savedefconfig will save a minimal config to a file
      named "defconfig".
      
      The config symbols are saved in the same order as
      they appear in the menu structure so it should
      be possible to map them to the relevant menus
      if desired.
      
      The implementation was tested against several minimal
      configs for arm which was created using brute-force.
      
      There was one regression related to default numbers
      which had their valid range further limited by another symbol.
      
      Sample:
      
      config FOO
      	int "foo"
      	default 4
      
      config BAR
      	int "bar"
      	range 0 FOO
      
      If FOO is set to 3 then BAR cannot take a value higher than 3.
      But the current implementation will set BAR equal to 4.
      
      This is seldomly used and the final configuration is OK,
      and the fix was non-trivial.
      So it was documented in the code and left as is.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      7cf3d73b
    • S
      kconfig: refactor code in symbol.c · c252147d
      Sam Ravnborg 提交于
      Move logic to determine default for a choice to
      a separate function.
      No functional changes.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      c252147d
  14. 02 2月, 2010 2 次提交
    • N
      kconfig: new configuration interface (nconfig) · 692d97c3
      nir.tzachar@gmail.com 提交于
      This patch was inspired by the kernel projects page, where an ncurses
      replacement for menuconfig was mentioned (by Sam Ravnborg).
      
      Building on menuconfig, this patch implements a more modern look
      interface using ncurses and ncurses' satellite libraries (menu, panel,
      form). The implementation does not depend on lxdialog, which is
      currently distributed with the kernel.
      Signed-off-by: NNir Tzachar <nir.tzachar@gmail.com>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      692d97c3
    • V
      menuconfig: wrap long help lines · da60fbbc
      Vadim Bendebury (вб) 提交于
      Help text for certain config options is very extensive (the text
      includes the names of all  other options the option in question depends
      on). Long lines are not wrapped, making it impossible to see the list
      without scrolling horizontally.
      
      This patch adds some logic which wraps help screen lines at word
      boundaries to prevent truncating.
      
      Tested by running
      
        ARCH=powerpc make menuconfig O=/tmp/build
      
      which shows that the long lines are now wrapped, and
      
       ARCH=powerpc make xconfig O=/tmp/build
      
      to demonstrate that it still compiles and operates as expected.
      Signed-off-by: NVadim Bendebury <vbendeb@google.com>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      da60fbbc
  15. 10 6月, 2009 1 次提交
  16. 26 7月, 2008 1 次提交
  17. 05 5月, 2008 1 次提交
  18. 29 1月, 2008 1 次提交
  19. 03 5月, 2007 1 次提交
  20. 14 12月, 2006 1 次提交
  21. 09 6月, 2006 4 次提交
  22. 09 11月, 2005 4 次提交
  23. 31 10月, 2005 1 次提交
  24. 29 7月, 2005 1 次提交
  25. 06 5月, 2005 1 次提交
    • A
      [PATCH] Kconfig i18n support · 3b9fa093
      Arnaldo Carvalho de Melo 提交于
      This patch adds i18n support for make *config, allowing users to have the
      config process in their own language.
      
      No printk was harmed in the process, don't worry, so all the bug reports,
      kernel messages, etc, remain in english, just the user tools to configure
      the kernel are internationalized.
      
      Users not interested in translations can just unset the related LANG,
      LC_ALL, etc env variables and have the config process in plain english,
      something like:
      
      LANG= make menuconfig
      
      is enough for having the whole config process in english. Or just don't
      install any translation file.
      
      Translations for brazilian portuguese are being done by a team of
      volunteers at:
      
      http://www.visionflex.inf.br/kernel_ptbr/pmwiki.php/Principal/Traducoes
      
      To start the translation process:
      
        make update-po-config
      
        This will generate the pot template named scripts/kconfig/linux.pot,
        copy it to, say, ~/es.po, to start the translation for spanish.
      
      To test your translation, as root issue this command:
      
        msgfmt -o /usr/share/locale/es/LC_MESSAGES/linux.mo ~/es.po
      
        Replace "es" with your language code.
      
        Then execute, for instance:
      
        make menuconfig
      
      The current patch doesn't use any optimization to reduce the size of the
      generated .mo file, it is possible to use the config option as a key, but
      this doesn't prevent the current patch from being used or the translations
      done under the current scheme to be in any way lost if we chose to do any
      kind of keying.
      
      Thanks to Fabricio Vaccari for starting the pt_BR (brazilian portuguese)
      translation effort, Thiago Maciera for helping me with the gconf.cc (QT
      frontent) i18n coding and to all the volunteers that are already working on
      the first translation, to pt_BR.
      
      I left the question on whether to ship the translations with the stock kernel
      sources to be discussed here, please share your suggestions.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@conectiva.com.br>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: Linus Torvalds <torvalds@osdl.org
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      3b9fa093