1. 09 2月, 2008 2 次提交
  2. 03 2月, 2008 3 次提交
    • 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_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
  3. 02 2月, 2008 1 次提交
  4. 28 1月, 2008 19 次提交
  5. 07 11月, 2007 2 次提交
  6. 31 10月, 2007 1 次提交
    • P
      sh: Clean up SR.RB Kconfig mess. · c81134b5
      Paul Mundt 提交于
      CPU_HAS_SR_RB is selected by both CPU_SH3 and CPU_SH4, so having a
      dependency and default y on those additionally doesn't make much sense.
      The select also has to be special cased for CPUs that don't support
      this.
      
      This is also something that has been abused too much as a result
      of being user-visible, hence the addition of the select in the first
      place. So just kill the user-visibility entirely while we're at it.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      c81134b5
  7. 30 10月, 2007 1 次提交
  8. 20 10月, 2007 1 次提交
  9. 28 9月, 2007 1 次提交
    • P
      sh: Conditionalize gUSA support. · 83662461
      Paul Mundt 提交于
      This conditionalizes gUSA support. gUSA is not supported on
      SMP configurations, and it's not necessary there anyways due
      to having other atomicity options (ie, movli.l/movco.l).
      
      Anything implementing the LL/SC semantics (all SH-4A CPUs)
      can switch to userspace atomicity implementations without
      requiring gUSA. This is left default-enabled on all UP so
      that glibc doesn't break.
      
      Those that know what they are doing can disable this explicitly.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      83662461
  10. 27 9月, 2007 1 次提交
  11. 21 9月, 2007 8 次提交