1. 08 4月, 2014 1 次提交
  2. 09 10月, 2013 1 次提交
  3. 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
  4. 25 10月, 2012 1 次提交
  5. 28 9月, 2012 2 次提交
  6. 15 1月, 2012 1 次提交
  7. 07 6月, 2011 1 次提交
  8. 15 4月, 2011 1 次提交
  9. 28 12月, 2010 1 次提交
  10. 22 12月, 2010 1 次提交
    • M
      kconfig: Make expr_copy() take a const argument · 17742dc7
      Michal Marek 提交于
      Fixes
      scripts/kconfig/expr.c: In function ‘expr_get_leftmost_symbol’:
      scripts/kconfig/expr.c:1026:2: warning: passing argument 1 of ‘expr_copy’ discards qualifiers from pointer target type
      scripts/kconfig/expr.c:67:14: note: expected ‘struct expr *’ but argument is of type ‘const struct expr *’
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      17742dc7
  11. 22 11月, 2010 1 次提交
  12. 04 10月, 2010 1 次提交
  13. 20 9月, 2010 1 次提交
  14. 03 8月, 2010 1 次提交
  15. 02 7月, 2010 1 次提交
    • C
      kbuild: Warn on selecting symbols with unmet direct dependencies · 246cf9c2
      Catalin Marinas 提交于
      The "select" statement in Kconfig files allows the enabling of options
      even if they have unmet direct dependencies (i.e. "depends on" expands
      to "no"). Currently, the "depends on" clauses are used in calculating
      the visibility but they do not affect the reverse dependencies in any
      way.
      
      The patch introduces additional tracking of the "depends on" statements
      and prints a warning on selecting an option if its direct dependencies
      are not met.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      246cf9c2
  16. 02 2月, 2010 1 次提交
    • A
      Improve kconfig symbol hashing · e66f25d7
      Andi Kleen 提交于
      While looking for something else I noticed that the symbol
      hash function used by kconfig is quite poor. It doesn't
      use any of the standard hash techniques but simply
      adds up the string and then uses power of two masking,
      which is both known to perform poorly.
      
      The current x86 kconfig has over 7000 symbols.
      
      When I instrumented it showed that the minimum hash chain
      length was 16 and a significant number of them was over
      30.
      
      It didn't help that the hash table size was only 256 buckets.
      
      This patch increases the hash table size to a larger prime
      and switches to a FNV32 hash. I played around with a couple of hash
      functions, but that one seemed to perform best with reasonable
      hash table sizes.
      
      Increasing the hash table size even further didn't
      seem like a good idea, because there are a couple of global
      walks which walk the complete hash table.
      
      I also moved the unnamed bucket to 0. It's still the longest
      of all the buckets (44 entries), but hopefully it's not
      often hit except for the global walk which doesn't care.
      
      The result is a much nicer distribution:
      (first column bucket length, second number of buckets with that length)
      
      1: 3505
      2: 1236
      3: 294
      4: 52
      5: 3
      47: 1		<--- this is the unnamed symbols bucket
      
      There are still some 5+ buckets, but increasing the hash table
      even more would be likely not worth it.
      
      This also cleans up the code slightly by removing hard coded
      magic numbers.
      
      I didn't notice a big performance difference either way
      on my Nehalem system, but I presume it'll help somewhat
      on slower systems.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      e66f25d7
  17. 03 1月, 2009 3 次提交
  18. 29 1月, 2008 4 次提交
  19. 26 7月, 2007 2 次提交
  20. 09 6月, 2006 5 次提交
  21. 09 11月, 2005 1 次提交
    • D
      [PATCH] kconfig: Fix Kconfig performance bug · 3f04e7dd
      David Gibson 提交于
      When doing its recursive dependency check, scripts/kconfig/conf uses the flag
      SYMBOL_CHECK_DONE to avoid rechecking a symbol it has already checked.
      However, that flag is only set at the top level, so if a symbol is first
      encountered as a dependency of another symbol it will be rechecked every time
      it is encountered until it's encountered at the top level.
      
      This patch adjusts the flag setting so that each symbol will only be checked
      once, regardless of whether it is first encountered at the top level, or while
      recursing down from another symbol.  On complex configurations, this vastly
      speeds up scripts/kconfig/conf.  The config in the powerpc merge tree is
      particularly bad: this patch reduces the time for 'scripts/kconfig/conf -o
      arch/powerpc/Kconfig' by a factor of 40 on a G5.  That's even including the
      time to print the config, so the speedup in the actual checking is more likely
      2 or 3 orders of magnitude.
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3f04e7dd
  22. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4