1. 03 Feb, 2008 8 commits
    • Mathieu Desnoyers's avatar
      Add HAVE_OPROFILE · 42d4b839
      Mathieu Desnoyers authored
      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: default avatarMathieu 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: default avatarSam Ravnborg <sam@ravnborg.org>
      42d4b839
    • Mathieu Desnoyers's avatar
      Create arch/Kconfig · fb32e03f
      Mathieu Desnoyers authored
      Puts the content of arch/Kconfig in the "General setup" menu.
      
      Linus:
      
      > Should it come with a re-duplication of it's content into each
      > architecture, which was the case previously ? The oprofile and kprobes
      > menu entries were litteraly cut and pasted from one architecture to
      > another. Should we put its content in init/Kconfig then ?
      
      I don't think it's a good idea to go back to making it per-architecture,
      although that extensive "depends on <list-of-archiectures-here>" might
      indicate that there certainly is room for cleanup there.
      
      And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I
      just think it's wrong to (a) lump the code together when it really doesn't
      necessarily need to and (b) show it to users as some kind of choice that
      is tied together (whether it then has common code or not).
      
      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...
      
      Sam Ravnborg:
      
      Stuff it into a new file: arch/Kconfig
      We can then extend this file to include all the 'trailing'
      Kconfig things that are anyway equal for all ARCHs.
      
      But it should be kept clean - so if we introduce such a file
      then we should use ARCH_HAS_whatever in the arch specific Kconfig
      files to enable stuff that is not shared.
      
      [...]
      
      The above suggestion is actually not exactly the best way to do it...
      First the naming..
      A quick grep shows following usage today (in Kconfig files)
      ARCH_HAS        51
      ARCH_SUPPORTS   4
      HAVE_ARCH       7
      
      ARCH_HAS is the clear winner.
      
      In the common Kconfig file do:
      
      config FOO
              depends on ARCH_HAS_FOO
              bool "bla bla"
      
      config ARCH_HAS_FOO
              def_bool n
      
      In the arch specific Kconfig file in a suitable place do:
      
      config SUITABLE_OPTION
              select ARCH_HAS_FOO
      
      The naming of ARCH_HAS_ is fixed and shall be:
      ARCH_HAS_<config option it will enable>
      
      Only a single line added pr. architecture.
      And we will end up with a (maybe even commented) list of trivial selects.
      
      - Yet another update :
      
      Moving to HAVE_* now.
      Signed-off-by: default avatarMathieu 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: default avatarSam Ravnborg <sam@ravnborg.org>
      fb32e03f
    • Mathieu Desnoyers's avatar
      Fix ARM to play nicely with generic Instrumentation menu · c0ffa3a9
      Mathieu Desnoyers authored
      The conflicting commit for
      move-kconfiginstrumentation-to-arch-kconfig-and-init-kconfig.patch
      is the ARM fix from Linus :
      
      commit 38ad9aeb
      
      He just seemed to agree that my approach (just putting the missing ARM
      config options in arch/arm/Kconfig) works too. The main advantage it has
      is that it is smaller, does not need a cleanup in the future and does
      not break the following patches unnecessarily.
      
      It's just been discussed here
      
      http://lkml.org/lkml/2008/1/15/267
      
      However, Linus might prefer to stay with his own patch and I would
      totally understand it that late in the release cycle. Therefore I submit
      this for the next release cycle.
      Signed-off-by: default avatarMathieu 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>
      CC: Russell King <rmk+lkml@arm.linux.org.uk>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      c0ffa3a9
    • Sam Ravnborg's avatar
      kconfig: ignore select of unknown symbol · 603d4988
      Sam Ravnborg authored
      We have had warnings for a long time about select of unknow symbol
      but the warnings does not really makes sense since we may
      select a symbol that is relevant and defined in one
      arch but not in another arch.
      And as long as we do not use a common set of Kconfig files
      for all archs lets just ignore this case.
      
      Previously we have used this to find bad uses of
      select but we need a more relaible method to do so.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      603d4988
    • Sam Ravnborg's avatar
      kconfig: mark config as changed when loading an alternate config · 36ef805b
      Sam Ravnborg authored
      Michal Zachar <mgzachar@mail.t-com.sk> reported that
      menuconfig did not save the new config when loading
      an alternate config unless he altered it manually.
      
      Mark config as changed upon load of alternate config fixed this.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Roman Zippel <zippel@linux-m68k.org>
      36ef805b
    • Geert Uytterhoeven's avatar
      kbuild: Spelling/grammar fixes for config DEBUG_SECTION_MISMATCH · d6fbfa4f
      Geert Uytterhoeven authored
      Including additional fixes from Randy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      d6fbfa4f
    • Ralf Baechle's avatar
      Remove __INIT_REFOK and __INITDATA_REFOK · 470a81ae
      Ralf Baechle authored
      Commit 312b1485 made __INIT_REFOK expand
      into .section .section ".ref.text", "ax".  Since the assembler doesn't
      tolerate stuttering in the source that broke all MIPS builds.
      
      Since with this change Sam downgraded __INIT_REFOK to just a backward
      compat thing and there being only a single use in the MIPS arch code the
      best solution is to delete both of __INIT_REFOK and __INITDATA_REFOK (which
      was equally broken) being unused anyway these can be deleted.
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      470a81ae
    • Sam Ravnborg's avatar
      kbuild: print only total number of section mismatces found · e5f95c8b
      Sam Ravnborg authored
      We have too many section mismatches detected at the moment.
      So silence modpost and prevent the option from being
      set in a typical allyesconfig build.
      
      Tell the user how to see all the deteils in the summary
      message from modpost.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      e5f95c8b
  2. 02 Feb, 2008 32 commits