3f550096de
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>
56 lines
1.5 KiB
Plaintext
56 lines
1.5 KiB
Plaintext
menuconfig INSTRUMENTATION
|
|
bool "Instrumentation Support"
|
|
default y
|
|
---help---
|
|
Say Y here to get to see options related to performance measurement,
|
|
system-wide debugging, and testing. This option alone does not add any
|
|
kernel code.
|
|
|
|
If you say N, all options in this submenu will be skipped and
|
|
disabled. If you're trying to debug the kernel itself, go see the
|
|
Kernel Hacking menu.
|
|
|
|
if INSTRUMENTATION
|
|
|
|
config PROFILING
|
|
bool "Profiling support (EXPERIMENTAL)"
|
|
help
|
|
Say Y here to enable the extended profiling support mechanisms used
|
|
by profilers such as OProfile.
|
|
|
|
config OPROFILE
|
|
tristate "OProfile system profiling (EXPERIMENTAL)"
|
|
depends on PROFILING && !UML
|
|
depends on HAVE_OPROFILE
|
|
help
|
|
OProfile is a profiling system capable of profiling the
|
|
whole system, include the kernel, kernel modules, libraries,
|
|
and applications.
|
|
|
|
If unsure, say N.
|
|
|
|
config HAVE_OPROFILE
|
|
def_bool n
|
|
|
|
config KPROBES
|
|
bool "Kprobes"
|
|
depends on KALLSYMS && MODULES && !UML
|
|
depends on HAVE_KPROBES
|
|
help
|
|
Kprobes allows you to trap at almost any kernel address and
|
|
execute a callback function. register_kprobe() establishes
|
|
a probepoint and specifies the callback. Kprobes is useful
|
|
for kernel debugging, non-intrusive instrumentation and testing.
|
|
If in doubt, say "N".
|
|
|
|
config HAVE_KPROBES
|
|
def_bool n
|
|
|
|
config MARKERS
|
|
bool "Activate markers"
|
|
help
|
|
Place an empty function call at each marker site. Can be
|
|
dynamically changed for a probe function.
|
|
|
|
endif # INSTRUMENTATION
|