summaryrefslogtreecommitdiffstats
path: root/kernel/Kconfig.instrumentation
Commit message (Collapse)AuthorAgeFilesLines
* Move Kconfig.instrumentation to arch/Kconfig and init/KconfigMathieu Desnoyers2008-02-031-55/+0
| | | | | | | | | | | | | | | | | | | | | | 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: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
* Add HAVE_KPROBESMathieu Desnoyers2008-02-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Mathieu 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: Sam Ravnborg <sam@ravnborg.org>
* Add HAVE_OPROFILEMathieu Desnoyers2008-02-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Mathieu 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: Sam Ravnborg <sam@ravnborg.org>
* Fix ARM to play nicely with generic Instrumentation menuMathieu Desnoyers2008-02-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The conflicting commit for move-kconfiginstrumentation-to-arch-kconfig-and-init-kconfig.patch is the ARM fix from Linus : commit 38ad9aebe70dc72df08851bbd1620d89329129ba 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: Mathieu 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: Sam Ravnborg <sam@ravnborg.org>
* Tiny clean-up of OPROFILE/KPROBES configurationLinus Torvalds2007-12-061-4/+4
| | | | | | | Make the Kconfig.instrumentation file a bit easier on the eyes, and use the new ARCH_SUPPORTS_OPROFILE for x86[-64]. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Fix oprofile configuration breakageRalf Baechle2007-12-061-1/+1
| | | | | | | | | | | | | | The cleanup 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9 broke the oprofile configuration for MIPS by allowing oprofile support to be built for kernel models where oprofile doesn't have a chance in hell to work. Just a dependecy list on a number of architectures is - surprise - broken and should as per past discussions probably in most considered to be broken in most cases. So I introduce a dependency for the oprofile configuration on ARCH_SUPPORTS_OPROFILE. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* uml: add !UML dependenciesAl Viro2007-12-031-2/+2
| | | | | | | | | | | The previous commit ("uml: keep UML Kconfig in sync with x86") is not enough, unfortunately. If we go that way, we need to add dependencies on !UML for several options. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Jeff Dike <jdike@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Linux Kernel MarkersMathieu Desnoyers2007-10-191-0/+6
| | | | | | | | | | | | | | | | | | | The marker activation functions sits in kernel/marker.c. A hash table is used to keep track of the registered probes and armed markers, so the markers within a newly loaded module that should be active can be activated at module load time. marker_query has been removed. marker_get_first, marker_get_next and marker_release should be used as iterators on the markers. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Acked-by: "Frank Ch. Eigler" <fche@redhat.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Mike Mason <mmlnx@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Combine instrumentation menus in kernel/Kconfig.instrumentationMathieu Desnoyers2007-10-191-0/+43
Quoting Randy: "It seems sad that this patch sources Kconfig.marker, a 7-line file, 20-something times. Yes, you (we) don't want to put those 7 lines into 20-something different files, so sourcing is the right thing. However, what you did for avr32 seems more on the right track to me: make _one_ Instrumentation support menu that includes PROFILING, OPROFILE, KPROBES, and MARKERS and then use (source) that in all of the arches." Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-20 06:27:13 +0000