Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
10 个月 前同步成功

通知 149
Star 36
Fork 7
cloud-kernel
cloud-kernel

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 03 2月, 2008 2 次提交
    • 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 次提交
  5. 28 1月, 2008 19 次提交
  7. 07 11月, 2007 2 次提交
  9. 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
  11. 30 10月, 2007 1 次提交
  13. 20 10月, 2007 1 次提交
  15. 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
  17. 27 9月, 2007 1 次提交
  19. 21 9月, 2007 8 次提交
  21. 26 7月, 2007 3 次提交