1. 09 11月, 2005 2 次提交
    • R
      [PATCH] kconfig: use gperf for kconfig keywords · 7a88488b
      Roman Zippel 提交于
      Use gperf to generate a hash for the kconfig keywords.  This greatly reduces
      the size of the generated scanner and makes it easier to extend kconfig.
      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>
      7a88488b
    • 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
  2. 29 7月, 2005 1 次提交
  3. 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