1. 07 2月, 2008 1 次提交
  2. 06 2月, 2008 2 次提交
  3. 04 2月, 2008 1 次提交
  4. 03 2月, 2008 4 次提交
    • A
      remove Documentation/smp.txt · 03502faa
      Adrian Bunk 提交于
      After seeing the filename I'd have expected something about the
      implementation of SMP in the Linux kernel - not some notes on kernel
      configuration and building trivialities noone would search at this
      place.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Acked-by: NAlan Cox <alan@redhat.com>
      03502faa
    • M
      Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig · 125e5645
      Mathieu Desnoyers 提交于
      Move the instrumentation Kconfig to
      
      arch/Kconfig for architecture dependent options
        - oprofile
        - kprobes
      
      and
      
      init/Kconfig for architecture independent options
        - profiling
        - markers
      
      Remove the "Instrumentation Support" menu. Everything moves to "General setup".
      Delete the kernel/Kconfig.instrumentation file.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      125e5645
    • M
      Add HAVE_KPROBES · 3f550096
      Mathieu Desnoyers 提交于
      Linus:
      
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config KPROBES_SUPPORT
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      - Use HAVE_KPROBES
      - Use a select
      
      - Yet another update :
      Moving to HAVE_* now.
      
      - Update ARM for kprobes support.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      3f550096
    • M
      Add HAVE_OPROFILE · 42d4b839
      Mathieu Desnoyers 提交于
      Linus:
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config ARCH_SUPPORTS_KPROBES
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      Changelog :
      
      - Moving to HAVE_*.
      - Add AVR32 oprofile.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      42d4b839
  5. 02 2月, 2008 4 次提交
  6. 31 1月, 2008 1 次提交
  7. 30 1月, 2008 22 次提交
  8. 07 12月, 2007 1 次提交
  9. 05 12月, 2007 1 次提交
  10. 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
  11. 13 11月, 2007 1 次提交
    • S
      x86: enable "make ARCH=x86" · daa93fab
      Sam Ravnborg 提交于
      After unification of the Kconfig files and
      introducing K64BIT support in kconfig
      it required only trivial changes to enable
      "make ARCH=x86".
      
      With this patch you can build for x86_64 in several ways:
      1) make ARCH=x86_64
      2) make ARCH=x86 K64BIT=y
      3) make ARCH=x86 menuconfig
         => select 64-bit
      
      Likewise for i386 with the addition that
      i386 is default is you say ARCH=x86.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      daa93fab