1. 16 3月, 2009 1 次提交
    • S
      kconfig: fix randconfig for choice blocks · 184832c9
      Sam Ravnborg 提交于
      Ingo Molnar reported that 'make randconfig' was not covering
      choice blocks properly, resulting in certain config options
      being left out of randconfig testing altogether.
      
      With the following patch we:
      - properly randomize choice value for normal choice blocks
      - properly randomize for multi choice blocks
      - added several comments to explain what is going on
      
      The root cause of the bug was that SYMBOL_VALID was set on the
      symbol representing the choice block so clearing this did
      the trick initially.
      But testign revealed a few more issues that is now fixed.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      184832c9
  2. 27 10月, 2008 1 次提交
    • A
      fix allmodconfig breakage · ce97e13e
      Al Viro 提交于
      If you use KCONFIG_ALLCONFIG (even with empty file) you get broken
      allmodconfig/allyesconfig; CONFIG_MODULES gets turned off, with obvious
      massive fallout.
      
      Breakage had been introduced when conf_set_all_new_symbols() got used
      for allmodconfig et.al.
      
      What happens is that sym_calc_value(modules_sym) done in
      conf_read_simple() sets SYMBOL_VALID on both modules_sym and MODULES.
      When we get to conf_set_all_new_symbols(), we set sym->def[S_DEF_USER]
      on everything, but it has no effect on sym->curr for the symbols that
      already have SYMBOL_VALID - these are stuck.
      
      Solution: use sym_clear_all_valid() in there.  Note that it makes
      reevaluation of modules_sym redundant - sym_clear_all_valid() will do
      that itself.
      
      [ Fixes http://bugzilla.kernel.org/show_bug.cgi?id=11512, says Alexey ]
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ce97e13e
  3. 29 9月, 2008 1 次提交
  4. 05 8月, 2008 1 次提交
  5. 26 7月, 2008 1 次提交
  6. 29 1月, 2008 3 次提交
  7. 18 11月, 2007 2 次提交
    • S
      x86: simplify "make ARCH=x86" and fix kconfig all.config · 6840999b
      Sam Ravnborg 提交于
      Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in
      all.config.
      
      For a fix the diffstat is nice:
       6 files changed, 3 insertions(+), 36 deletions(-)
      
      The patch reverts these commits:
       - 0f855aa6 ("kconfig: add helper to set
         config symbol from environment variable")
       - 2a113281 ("kconfig: use $K64BIT to
         set 64BIT with all*config targets")
      
      Roman Zippel pointed out that kconfig supported string compares so
      the additional complexity introduced by the above two patches were
      not needed.
      
      With this patch we have following behaviour:
      
        # make {allno,allyes,allmod,rand}config [ARCH=...]
        option \ host arch      | 32bit         | 64bit
        =====================================================
        ./.                     | 32bit         | 64bit
        ARCH=x86                | 32bit         | 32bit
        ARCH=i386               | 32bit         | 32bit
        ARCH=x86_64             | 64bit         | 64bit
      
      The general rule are that ARCH= and native architecture takes
      precedence over the configuration.
      
      So make ARCH=i386 [whatever] will always build a 32-bit kernel
      no matter what the configuration says.  The configuration will
      be updated to 32-bit if it was configured to 64-bit and the
      other way around.
      
      This behaviour is consistent with previous behaviour so no
      suprises here.
      
      make ARCH=x86 will per default result in a 32-bit kernel but as
      the only ARCH= value x86 allow the user to select between 32-bit
      and 64-bit using menuconfig.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Andreas Herrmann <aherrman@arcor.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6840999b
    • S
      x86: simplify "make ARCH=x86" and fix kconfig all.config · 80ef88d6
      Sam Ravnborg 提交于
      Simplify "make ARCH=x86" and fix kconfig so we again
      can set 64BIT in all.config.
      
      For a fix the diffstat is nice:
       6 files changed, 3 insertions(+), 36 deletions(-)
      
      The patch reverts these commits:
      0f855aa6
      -> kconfig: add helper to set config symbol from environment variable
      
      2a113281
      -> kconfig: use $K64BIT to set 64BIT with all*config targets
      
      Roman Zippel pointed out that kconfig supported string
      compares so the additional complexity introduced by the
      above two patches were not needed.
      
      With this patch we have following behaviour:
      
      # make {allno,allyes,allmod,rand}config [ARCH=...]
      option \ host arch      | 32bit         | 64bit
      =====================================================
      ./.                     | 32bit         | 64bit
      ARCH=x86                | 32bit         | 32bit
      ARCH=i386               | 32bit         | 32bit
      ARCH=x86_64             | 64bit         | 64bit
      
      The general rule are that ARCH= and native architecture
      takes precedence over the configuration.
      So make ARCH=i386 [whatever] will always build a 32-bit
      kernel no matter what the configuration says.
      The configuration will be updated to 32-bit if it was
      configured to 64-bit and the other way around.
      
      This behaviour is consistent with previous behaviour so
      no suprises here.
      
      make ARCH=x86 will per default result in a 32-bit kernel
      but as the only ARCH= value x86 allow the user to select
      between 32-bit and 64-bit using menuconfig. 
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Andreas Herrmann <aherrman@arcor.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      80ef88d6
  8. 13 11月, 2007 2 次提交
  9. 17 7月, 2007 1 次提交
    • R
      kconfig: reset generated values only if Kconfig and .config agree. · d8982ba1
      Roman Zippel 提交于
      Normally generated values (Kconfig entries without a prompt) are cleared as
      they are regenerated anyway and so they appear as new should they become
      visible and defaults work as expected (once a value is set defaults aren't
      used anymore).
      
      The detection whether a value is generated or not is only based on its
      visibility status, which can quickly change for a lot of symbols by just
      removing a single line from .config or adding a dependency to Kconfig as you
      noticed.
      
      The patch now suppresses this logic when .config and Kconfig aren't in sync
      and .config needs to be updated, so that you can remove now a random value
      from .config and oldconfig won't reask for many other values.
      Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      d8982ba1
  10. 14 12月, 2006 3 次提交
  11. 01 10月, 2006 1 次提交
  12. 25 9月, 2006 1 次提交
  13. 01 8月, 2006 1 次提交
  14. 09 6月, 2006 7 次提交
  15. 11 4月, 2006 1 次提交
  16. 13 3月, 2006 1 次提交
  17. 16 1月, 2006 1 次提交
    • S
      kbuild: create .kernelrelease at *config step · 2244cbd8
      Sam Ravnborg 提交于
      To enable 'make kernelrelease' earlier now create .kernelrelease when
      one of the *config targets are used.
      Also introduce KERNELVERSION - only user is kconfig.
      KERNELVERSION was needed to display kernel version in menuconfig -
      KERNELRELEASE is not valid until configuration has completed.
      kconfig files modified to use KERNELVERSION.
      Bug reported by: Rene Rebe <rene@exactcode.de>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      2244cbd8
  18. 09 11月, 2005 2 次提交
  19. 26 6月, 2005 1 次提交
  20. 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
  21. 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