]> pilppa.com Git - linux-2.6-omap-h63xx.git/commit
Add HAVE_KPROBES
authorMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Sat, 2 Feb 2008 20:10:35 +0000 (15:10 -0500)
committerSam Ravnborg <sam@ravnborg.org>
Sun, 3 Feb 2008 07:58:07 +0000 (08:58 +0100)
commit3f550096dede4430f83b16457da83bf429155ac2
tree1e352deedbcf23cf97a4ca5a2db7f26dd26a4640
parent42d4b839c82fd7dd8e412145eb6d9752468478e2
Add HAVE_KPROBES

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>
arch/arm/Kconfig
arch/avr32/Kconfig
arch/ia64/Kconfig
arch/powerpc/Kconfig
arch/ppc/Kconfig
arch/s390/Kconfig
arch/sparc64/Kconfig
arch/x86/Kconfig
kernel/Kconfig.instrumentation