talos-op-linux/kernel/Kconfig.instrumentation, branch master

Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig

2008-02-03T07:58:08+00:00

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 Cc: Linus Torvalds Cc: Signed-off-by: Sam Ravnborg

Add HAVE_KPROBES

2008-02-03T07:58:07+00:00

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 Cc: Jeff Dike Cc: David Howells Cc: Ananth N Mavinakayanahalli Signed-off-by: Sam Ravnborg

Add HAVE_OPROFILE

2008-02-03T07:58:07+00:00

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 Cc: Andrew Morton Cc: Haavard Skinnemoen Cc: David Howells Cc: Jeff Dike Cc: Ananth N Mavinakayanahalli Signed-off-by: Sam Ravnborg

Fix ARM to play nicely with generic Instrumentation menu

2008-02-03T07:58:07+00:00

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 Cc: Jeff Dike Cc: David Howells Cc: Ananth N Mavinakayanahalli CC: Russell King Signed-off-by: Sam Ravnborg

Tiny clean-up of OPROFILE/KPROBES configuration

2007-12-06T17:41:12+00:00

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

Fix oprofile configuration breakage

2007-12-06T17:37:03+00:00

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 Signed-off-by: Linus Torvalds

uml: add !UML dependencies

2007-12-03T16:13:17+00:00

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 Signed-off-by: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Linux Kernel Markers

2007-10-19T18:53:54+00:00

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 Acked-by: "Frank Ch. Eigler" Cc: Christoph Hellwig Cc: Rusty Russell Cc: Mike Mason Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Combine instrumentation menus in kernel/Kconfig.instrumentation

2007-10-19T18:53:54+00:00

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 Acked-by: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds