Instrumentation menu removal, against 2.6.24-rc4-mm1 (mmotm)
Subsystems (12)
cover Instrumentation menu removal, against 2.6.24-rc4-mm1 (mmotm)
Hi Andrew,
This time I am taking no chance :
The instrumentation menu removal patchset here applies against 2.6.24-rc4-mm1 _and_ against mmotm (dated : stamp-2007-12-05-15-24) without problem.
We should hopefully be able to stop racing against other architecture specific fixes done underneath. Please be aware that the following fix :
- fix-oprofile-configuration-breakage.patch
from MIPS did not show up in your mmotm tree. I guess you just sent it upstream without keeping it in your own tree. I have applied the content of this fix in my patchset (meaning : select HAVE_OPROFILE if !MIPS_MT_SMTC in add-have-oprofile.patch), but I think you might have a reject if you still have this fix-oprofile-configuration-breakage.patch in your local tree but not in mmotm.
Mathieu
Signature · 3 lines
Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
PATCH 1/4 Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu.
Linus:
Quoted 4 lines
Should it come with a re-duplication of it's content into each architecture, which was the case previously ? The oprofile and kprobes menu entries were litteraly cut and pasted from one architecture to another. Should we put its content in init/Kconfig then ?
I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on <list-of-archiectures-here>" might indicate that there certainly is room for cleanup there.
And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not).
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...
Sam Ravnborg:
Stuff it into a new file: arch/Kconfig
We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs.
But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared.
[...]
The above suggestion is actually not exactly the best way to do it... First the naming..
A quick grep shows following usage today (in Kconfig files)
ARCH_HAS 51 ARCH_SUPPORTS 4 HAVE_ARCH 7
ARCH_HAS is the clear winner.
In the common Kconfig file do:
config FOO
depends on ARCH_HAS_FOO
bool "bla bla"
config ARCH_HAS_FOO
def_bool n
In the arch specific Kconfig file in a suitable place do:
config SUITABLE_OPTION
select ARCH_HAS_FOO
The naming of ARCH_HAS_ is fixed and shall be:
ARCH_HAS_<config option it will enable>
Only a single line added pr. architecture.
And we will end up with a (maybe even commented) list of trivial selects.
- Yet another update :
Moving to HAVE_* now.
--- arch/Kconfig | 3 +++ init/Kconfig | 2 ++ 2 files changed, 5 insertions(+)
init/Kconfig +2 -0
@@ -701,6 +701,8 @@ config PROC_PAGE_MONITOR /proc/kpagecount, and /proc/kpageflags. Disabling these interfaces will reduce the size of the kernel by approximately 4kb. +source "arch/Kconfig" + endmenu # General setup config RT_MUTEXES
arch/Kconfig new file +3 -0
@@ -0,0 +1,3 @@ +# +# General architecture dependent options +#
Signature · 3 lines
Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
PATCH 2/4 Add HAVE_OPROFILE
In reply to Mathieu DesnoyersLinus:
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.
--- arch/alpha/Kconfig | 1 + arch/arm/Kconfig | 1 + arch/avr32/Kconfig | 1 + arch/blackfin/Kconfig | 1 + arch/ia64/Kconfig | 1 + arch/m32r/Kconfig | 1 + arch/mips/Kconfig | 1 + arch/parisc/Kconfig | 1 + arch/powerpc/Kconfig | 1 + arch/ppc/Kconfig | 1 + arch/s390/Kconfig | 1 + arch/sh/Kconfig | 1 + arch/sparc/Kconfig | 1 + arch/sparc64/Kconfig | 1 + arch/x86/Kconfig | 1 + kernel/Kconfig.instrumentation | 5 ++++- 16 files changed, 19 insertions(+), 1 deletion(-)
kernel/Kconfig.instrumentation +4 -1
@@ -21,7 +21,7 @@ config PROFILING config OPROFILE tristate "OProfile system profiling (EXPERIMENTAL)" depends on PROFILING && !UML - depends on ALPHA || ARM || AVR32 || BLACKFIN || X86_32 || IA64 || M32R || MIPS || PARISC || PPC || S390 || SUPERH || SPARC || X86_64 + depends on HAVE_OPROFILE help OProfile is a profiling system capable of profiling the whole system, include the kernel, kernel modules, libraries,
@@ -29,6 +29,9 @@ config OPROFILE If unsure, say N. +config HAVE_OPROFILE + def_bool n + config KPROBES bool "Kprobes" depends on KALLSYMS && MODULES
arch/alpha/Kconfig +1 -0
@@ -5,6 +5,7 @@ config ALPHA bool default y + select HAVE_OPROFILE help The Alpha is a 64-bit general-purpose processor designed and marketed by the Digital Equipment Corporation of blessed memory,
arch/arm/Kconfig +1 -0
@@ -10,6 +10,7 @@ config ARM default y select RTC_LIB select SYS_SUPPORTS_APM_EMULATION + select HAVE_OPROFILE help The ARM series is a line of low-power-consumption RISC chip designs licensed by ARM Ltd and targeted at embedded applications and
arch/blackfin/Kconfig +1 -0
@@ -24,6 +24,7 @@ config RWSEM_XCHGADD_ALGORITHM config BLACKFIN bool default y + select HAVE_OPROFILE config ZONE_DMA bool
arch/ia64/Kconfig +1 -0
@@ -15,6 +15,7 @@ config IA64 select ACPI if (!IA64_HP_SIM) select PM if (!IA64_HP_SIM) select ARCH_SUPPORTS_MSI + select HAVE_OPROFILE default y help The Itanium Processor Family is Intel's 64-bit successor to
arch/m32r/Kconfig +1 -0
@@ -8,6 +8,7 @@ mainmenu "Linux/M32R Kernel Configuratio config M32R bool default y + select HAVE_OPROFILE config SBUS bool
arch/mips/Kconfig +1 -0
@@ -1,6 +1,7 @@ config MIPS bool default y + select HAVE_OPROFILE if !MIPS_MT_SMTC # Horrible source of confusion. Die, die, die ... select EMBEDDED select RTC_LIB
arch/parisc/Kconfig +1 -0
@@ -7,6 +7,7 @@ mainmenu "Linux/PA-RISC Kernel Configura config PARISC def_bool y + select HAVE_OPROFILE help The PA-RISC microprocessor is designed by Hewlett-Packard and used in many of their workstations & servers (HP9000 700 and 800 series,
arch/powerpc/Kconfig +1 -0
@@ -79,6 +79,7 @@ config ARCH_NO_VIRT_TO_BUS config PPC bool default y + select HAVE_OPROFILE config EARLY_PRINTK bool
arch/ppc/Kconfig +1 -0
@@ -42,6 +42,7 @@ config GENERIC_CALIBRATE_DELAY config PPC bool default y + select HAVE_OPROFILE config PPC32 bool
arch/s390/Kconfig +1 -0
@@ -51,6 +51,7 @@ mainmenu "Linux Kernel Configuration" config S390 def_bool y + select HAVE_OPROFILE source "init/Kconfig"
arch/sh/Kconfig +1 -0
@@ -8,6 +8,7 @@ mainmenu "Linux/SuperH Kernel Configurat config SUPERH def_bool y select EMBEDDED + select HAVE_OPROFILE help The SuperH is a RISC processor targeted for use in embedded systems and consumer electronics; it was also used in the Sega Dreamcast
arch/sparc/Kconfig +1 -0
@@ -66,6 +66,7 @@ config NR_CPUS config SPARC bool default y + select HAVE_OPROFILE # Identify this as a Sparc32 build config SPARC32
arch/sparc64/Kconfig +1 -0
@@ -8,6 +8,7 @@ mainmenu "Linux/UltraSPARC Kernel Config config SPARC bool default y + select HAVE_OPROFILE config SPARC64 bool
arch/x86/Kconfig +1 -0
@@ -18,6 +18,7 @@ config X86_64 ### Arch settings config X86 def_bool y + select HAVE_OPROFILE config GENERIC_TIME def_bool y
arch/avr32/Kconfig +1 -0
@@ -10,6 +10,7 @@ config AVR32 # With EMBEDDED=n, we get lots of stuff automatically selected # that we usually don't need on AVR32. select EMBEDDED + select HAVE_OPROFILE help AVR32 is a high-performance 32-bit RISC microprocessor core, designed for cost-sensitive embedded applications, with particular
Signature · 3 lines
Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
Re: [patch 2/4] Add HAVE_OPROFILE
kernel/Kconfig.instrumentation config PROFILING · line 27
Quoted 9 lines · On Sat, 08 Dec 2007 10:32:57 -0500 Mathieu Desnoyers…
kernel/Kconfig.instrumentation +1
-1@@ -21,7 +21,7 @@ config PROFILING config OPROFILE tristate "OProfile system profiling (EXPERIMENTAL)" depends on PROFILING && !UML - depends on ALPHA || ARM || AVR32 || BLACKFIN || X86_32 || IA64 || M32R || MIPS || PARISC || PPC || S390 || SUPERH || SPARC || X86_64 + depends on HAVE_OPROFILE help OProfile is a profiling system capable of profiling the whole system, include the kernel, kernel modules, libraries,
So the "&& !UML" in there shold now be obsolete? I removed it...
Ditto the one for KPROBES.
PATCH 3/4 Add HAVE_KPROBES
In reply to Mathieu DesnoyersLinus:
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.
--- arch/avr32/Kconfig | 1 + arch/ia64/Kconfig | 1 + arch/powerpc/Kconfig | 1 + arch/ppc/Kconfig | 1 + arch/s390/Kconfig | 1 + arch/sparc64/Kconfig | 1 + arch/x86/Kconfig | 1 + kernel/Kconfig.instrumentation | 5 ++++- 8 files changed, 11 insertions(+), 1 deletion(-)
arch/avr32/Kconfig +1 -0
@@ -11,6 +11,7 @@ config AVR32 # that we usually don't need on AVR32. select EMBEDDED select HAVE_OPROFILE + select HAVE_KPROBES help AVR32 is a high-performance 32-bit RISC microprocessor core, designed for cost-sensitive embedded applications, with particular
arch/ia64/Kconfig +1 -0
@@ -16,6 +16,7 @@ config IA64 select PM if (!IA64_HP_SIM) select ARCH_SUPPORTS_MSI select HAVE_OPROFILE + select HAVE_KPROBES default y help The Itanium Processor Family is Intel's 64-bit successor to
arch/powerpc/Kconfig +1 -0
@@ -80,6 +80,7 @@ config PPC bool default y select HAVE_OPROFILE + select HAVE_KPROBES config EARLY_PRINTK bool
arch/ppc/Kconfig +1 -0
@@ -43,6 +43,7 @@ config PPC bool default y select HAVE_OPROFILE + select HAVE_KPROBES config PPC32 bool
arch/s390/Kconfig +1 -0
@@ -52,6 +52,7 @@ mainmenu "Linux Kernel Configuration" config S390 def_bool y select HAVE_OPROFILE + select HAVE_KPROBES source "init/Kconfig"
arch/sparc64/Kconfig +1 -0
@@ -9,6 +9,7 @@ config SPARC bool default y select HAVE_OPROFILE + select HAVE_KPROBES config SPARC64 bool
kernel/Kconfig.instrumentation +4 -1
@@ -35,7 +35,7 @@ config HAVE_OPROFILE config KPROBES bool "Kprobes" depends on KALLSYMS && MODULES - depends on (X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32) && !UML + depends on HAVE_KPROBES help Kprobes allows you to trap at almost any kernel address and execute a callback function. register_kprobe() establishes
@@ -43,6 +43,9 @@ config KPROBES 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
arch/x86/Kconfig +1 -0
@@ -19,6 +19,7 @@ config X86_64 config X86 def_bool y select HAVE_OPROFILE + select HAVE_KPROBES config GENERIC_TIME def_bool y
Signature · 3 lines
Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
PATCH 4/4 Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig
In reply to Mathieu DesnoyersMove 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.
--- arch/Kconfig | 28 ++++++++++++++++++++ arch/alpha/Kconfig | 2 - arch/arm/Kconfig | 2 - arch/blackfin/Kconfig | 2 - arch/cris/Kconfig | 2 - arch/frv/Kconfig | 2 - arch/h8300/Kconfig | 2 - arch/ia64/Kconfig | 2 - arch/m32r/Kconfig | 2 - arch/m68k/Kconfig | 2 - arch/m68knommu/Kconfig | 2 - arch/mips/Kconfig | 2 - arch/parisc/Kconfig | 2 - arch/powerpc/Kconfig | 2 - arch/ppc/Kconfig | 2 - arch/s390/Kconfig | 2 - arch/sh/Kconfig | 2 - arch/sparc/Kconfig | 2 - arch/sparc64/Kconfig | 2 - arch/um/Kconfig | 2 - arch/v850/Kconfig | 2 - arch/x86/Kconfig | 2 - arch/xtensa/Kconfig | 2 - init/Kconfig | 12 ++++++++ kernel/Kconfig.instrumentation | 55 ----------------------------------------- 25 files changed, 40 insertions(+), 99 deletions(-)
arch/Kconfig +28 -0
@@ -1,3 +1,31 @@ # # General architecture dependent options # + +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 + 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
init/Kconfig +12 -0
@@ -701,6 +701,18 @@ config PROC_PAGE_MONITOR /proc/kpagecount, and /proc/kpageflags. Disabling these interfaces will reduce the size of the kernel by approximately 4kb. +config PROFILING + bool "Profiling support (EXPERIMENTAL)" + help + Say Y here to enable the extended profiling support mechanisms used + by profilers such as OProfile. + +config MARKERS + bool "Activate markers" + help + Place an empty function call at each marker site. Can be + dynamically changed for a probe function. + source "arch/Kconfig" endmenu # General setup
arch/alpha/Kconfig +0 -2
@@ -658,8 +658,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/alpha/Kconfig.debug" # DUMMY_CONSOLE may be defined in drivers/video/console/Kconfig
arch/arm/Kconfig +0 -2
@@ -1077,8 +1077,6 @@ endmenu source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/arm/Kconfig.debug" source "security/Kconfig"
arch/blackfin/Kconfig +0 -2
@@ -995,8 +995,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/blackfin/Kconfig.debug" source "security/Kconfig"
arch/cris/Kconfig +0 -2
@@ -214,8 +214,6 @@ source "drivers/pci/Kconfig" source "drivers/usb/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/cris/Kconfig.debug" source "security/Kconfig"
arch/frv/Kconfig +0 -2
@@ -384,8 +384,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/frv/Kconfig.debug" source "security/Kconfig"
arch/h8300/Kconfig +0 -2
@@ -226,8 +226,6 @@ endmenu source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/h8300/Kconfig.debug" source "security/Kconfig"
arch/ia64/Kconfig +0 -2
@@ -594,8 +594,6 @@ config IRQ_PER_CPU source "arch/ia64/hp/sim/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/ia64/Kconfig.debug" source "security/Kconfig"
arch/m32r/Kconfig +0 -2
@@ -430,8 +430,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/m32r/Kconfig.debug" source "security/Kconfig"
arch/m68k/Kconfig +0 -2
@@ -672,8 +672,6 @@ endmenu source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/m68k/Kconfig.debug" source "security/Kconfig"
arch/m68knommu/Kconfig +0 -2
@@ -710,8 +710,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/m68knommu/Kconfig.debug" source "security/Kconfig"
arch/mips/Kconfig +0 -2
@@ -2072,8 +2072,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/mips/Kconfig.debug" source "security/Kconfig"
arch/parisc/Kconfig +0 -2
@@ -271,8 +271,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/parisc/Kconfig.debug" source "security/Kconfig"
arch/powerpc/Kconfig +0 -2
@@ -682,8 +682,6 @@ source "arch/powerpc/sysdev/qe_lib/Kconf source "lib/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/powerpc/Kconfig.debug" source "security/Kconfig"
arch/ppc/Kconfig +0 -2
@@ -1319,8 +1319,6 @@ endmenu source "lib/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/ppc/Kconfig.debug" source "security/Kconfig"
arch/s390/Kconfig +0 -2
@@ -531,8 +531,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/s390/Kconfig.debug" source "security/Kconfig"
arch/sh/Kconfig +0 -2
@@ -892,8 +892,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/sh/Kconfig.debug" source "security/Kconfig"
arch/sparc/Kconfig +0 -2
@@ -324,8 +324,6 @@ endmenu source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/sparc/Kconfig.debug" source "security/Kconfig"
arch/sparc64/Kconfig +0 -2
@@ -467,8 +467,6 @@ source "drivers/sbus/char/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/sparc64/Kconfig.debug" source "security/Kconfig"
arch/um/Kconfig +0 -2
@@ -288,6 +288,4 @@ config INPUT bool default n -source "kernel/Kconfig.instrumentation" - source "arch/um/Kconfig.debug"
arch/v850/Kconfig +0 -2
@@ -334,8 +334,6 @@ source "sound/Kconfig" source "drivers/usb/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/v850/Kconfig.debug" source "security/Kconfig"
arch/xtensa/Kconfig +0 -2
@@ -251,8 +251,6 @@ config EMBEDDED_RAMDISK_IMAGE provide one yourself. endmenu -source "kernel/Kconfig.instrumentation" - source "arch/xtensa/Kconfig.debug" source "security/Kconfig"
arch/x86/Kconfig +0 -2
@@ -1582,8 +1582,6 @@ source "drivers/firmware/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/x86/Kconfig.debug" source "security/Kconfig"
kernel/Kconfig.instrumentation deleted +0 -55
55 lines not on this page · raw message
Signature · 3 lines
Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
Re: [patch 4/4] Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig
arch/Kconfig line 8
Quoted 4 lines · On Sat, 08 Dec 2007 10:32:59 -0500 Mathieu Desnoyers…
arch/Kconfig +4
-0+config OPROFILE + tristate "OProfile system profiling (EXPERIMENTAL)" + depends on PROFILING && !UML + depends on HAVE_OPROFILE
And I removed the !UML here. UML shouldn't be setting HAVE_OPROFILE.
Quoted 10 lines · Mathieu Desnoyers
Hi Andrew,
This time I am taking no chance :
The instrumentation menu removal patchset here applies against 2.6.24-rc4-mm1 _and_ against mmotm (dated : stamp-2007-12-05-15-24) without problem.
We should hopefully be able to stop racing against other architecture specific fixes done underneath. Please be aware that the following fix :
Quoted 8 lines
- fix-oprofile-configuration-breakage.patch
from MIPS did not show up in your mmotm tree. I guess you just sent it upstream without keeping it in your own tree. I have applied the content of this fix in my patchset (meaning : select
HAVE_OPROFILEif !MIPS_MT_SMTC in add-have-oprofile.patch), but I think you might have a reject if you still have this fix-oprofile-configuration-breakage.patch in your local tree but not in mmotm.
Mathieu,
With this patchset, a `make defconfig' results in:
CONFIG_OPROFILE=yCONFIG_HAVE_OPROFILE=yCONFIG_KPROBES=yCONFIG_HAVE_KPROBES=y
You probably also need to change the defconfigs...
Ananth
Quoted 22 lines · Ananth N Mavinakayanahalli
Quoted 10 lines · Mathieu Desnoyers
Hi Andrew,
This time I am taking no chance :
The instrumentation menu removal patchset here applies against 2.6.24-rc4-mm1 _and_ against mmotm (dated : stamp-2007-12-05-15-24) without problem.
We should hopefully be able to stop racing against other architecture specific fixes done underneath. Please be aware that the following fix :
Quoted 8 lines
- fix-oprofile-configuration-breakage.patch
from MIPS did not show up in your mmotm tree. I guess you just sent it upstream without keeping it in your own tree. I have applied the content of this fix in my patchset (meaning : select
HAVE_OPROFILEif !MIPS_MT_SMTC in add-have-oprofile.patch), but I think you might have a reject if you still have this fix-oprofile-configuration-breakage.patch in your local tree but not in mmotm.Mathieu,
Quoted 8 lines
With this patchset, a `make defconfig' results in:
CONFIG_OPROFILE=yCONFIG_HAVE_OPROFILE=yCONFIG_KPROBES=yCONFIG_HAVE_KPROBES=yYou probably also need to change the defconfigs...
Nevermind. If the intention is to key off the build based on CONFIG_<FOO> and have the CONFIG_HAVE_<FOO> settings just to make the config simpler, this change is fine. The side effect is just that the CONFIG_HAVE_<FOO> will still have default settings even when CONFIG_<FOO> is not set.
Ananth
Quoted 30 lines · * Ananth N Mavinakayanahalli ([email protected]) wrote:
Quoted 29 lines · Ananth N Mavinakayanahalli
Quoted 10 lines · Mathieu Desnoyers
Hi Andrew,
This time I am taking no chance :
The instrumentation menu removal patchset here applies against 2.6.24-rc4-mm1 _and_ against mmotm (dated : stamp-2007-12-05-15-24) without problem.
We should hopefully be able to stop racing against other architecture specific fixes done underneath. Please be aware that the following fix :
Quoted 8 lines
- fix-oprofile-configuration-breakage.patch
from MIPS did not show up in your mmotm tree. I guess you just sent it upstream without keeping it in your own tree. I have applied the content of this fix in my patchset (meaning : select
HAVE_OPROFILEif !MIPS_MT_SMTC in add-have-oprofile.patch), but I think you might have a reject if you still have this fix-oprofile-configuration-breakage.patch in your local tree but not in mmotm.Mathieu,
With this patchset, a `make defconfig' results in:
CONFIG_OPROFILE=yCONFIG_HAVE_OPROFILE=yCONFIG_KPROBES=yCONFIG_HAVE_KPROBES=y
Quoted 7 lines
Quoted 1 line
You probably also need to change the defconfigs...
Nevermind. If the intention is to key off the build based on CONFIG_<FOO> and have the CONFIG_HAVE_<FOO> settings just to make the config simpler, this change is fine. The side effect is just that the CONFIG_HAVE_<FOO> will still have default settings even when CONFIG_<FOO> is not set.
On x86_32, a diff between defconfig before and after the patchset :
97a98,103
Quoted 6 lines
CONFIG_PROFILING=y
#CONFIG_MARKERSis not setCONFIG_OPROFILE=yCONFIG_HAVE_OPROFILE=yCONFIG_KPROBES=yCONFIG_HAVE_KPROBES=y
1401,1405d1406
< CONFIG_INSTRUMENTATION=y
< CONFIG_PROFILING=y
< CONFIG_OPROFILE=y
< CONFIG_KPROBES=y
< # CONFIG_MARKERS is not set
Shows the same result. As you explain in your message, the HAVE_* is just a way to know if the architecture provides a feature. The menu entry is CONFIG_<FOO>, which depends on CONFIG_HAVE_<FOO>, will allow y/n/m selection.
Mathieu
Signature · 3 lines
Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68