| Message ID | 20190405194613.19578-1-u.kleine-koenig@pengutronix.de |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] tracing: stop making gpio tracing configurable | expand |
On 05.04.19 21:46, Uwe Kleine-König wrote: > gpio tracing was made configurable in 4.4-rc1 (commit ddd70280bf0e > ("tracing: gpio: Add Kconfig option for enabling/disabling trace > events")). Since then it is the only event type that can be compiled > conditionally. Given that there is only little overhead I don't > understand the reasoning and I was annoyed more than once that gpio > events were not available without recompiling. why 'default y' is not sufficient ? --mtx
Hello Enrico, On Sat, Apr 06, 2019 at 07:20:37PM +0200, Enrico Weigelt, metux IT consult wrote: > On 05.04.19 21:46, Uwe Kleine-König wrote: > > gpio tracing was made configurable in 4.4-rc1 (commit ddd70280bf0e > > ("tracing: gpio: Add Kconfig option for enabling/disabling trace > > events")). Since then it is the only event type that can be compiled > > conditionally. Given that there is only little overhead I don't > > understand the reasoning and I was annoyed more than once that gpio > > events were not available without recompiling. > > why 'default y' is not sufficient ? I don't know. The kernels I stumbled over which had that disabled were not configured by me. One public instance that disabled it (without reasoning though) is commit 20c90af9ea6a. I assume it is done without explicit justification in most of the cases. There are just too many options you could care about. So reducing the number of options is a good direction in my eyes. Best regards Uwe
On 06.04.19 23:06, Uwe Kleine-König wrote: Hi, >> why 'default y' is not sufficient ? > > I don't know. The kernels I stumbled over which had that disabled were > not configured by me. hmm, so probably the one who configured it in the first place did it wrong. but the same could happen w/ any other option. > There are just too many options you could care about. Right, this has become pretty complex. One thing I really dislike is the fact that some options are only reachable when certain others are enabled before, so sou cant just do echo "CONFIG_FOO=y" >> .config and hope that this does it. And often, you just wanna switch on some highlevel feature like networking, but have to configure lots of other things (nic, phy, ip stack, ...) I've written a little tool for helping w/ that: https://github.com/metux/kmct (I'm planning to integrate it into ptxdist, once I've got some spare time again ;-)). > So reducing the number of options is a good direction in my eyes. Well, depends ;-) In that specific case, you're probably right (at least I haven't had a usecase for having trace enabled, but gpio trace disabled, yet). But we both know that in embedded world we often need to trim down the kernel. So, ACK for the general idea, but haven't actually tested the patch yet. --mtx
On Fri, Apr 5, 2019 at 9:46 PM Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > gpio tracing was made configurable in 4.4-rc1 (commit ddd70280bf0e > ("tracing: gpio: Add Kconfig option for enabling/disabling trace > events")). Since then it is the only event type that can be compiled > conditionally. Given that there is only little overhead I don't > understand the reasoning and I was annoyed more than once that gpio > events were not available without recompiling. > > So drop the Kconfig symbol and make gpio events available > unconditionally. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Patch applied. Yours, Linus Walleij
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig index 1446262921b4..0f3638dd576b 100644 --- a/arch/arm/configs/aspeed_g4_defconfig +++ b/arch/arm/configs/aspeed_g4_defconfig @@ -248,7 +248,6 @@ CONFIG_PANIC_TIMEOUT=-1 # CONFIG_SCHED_DEBUG is not set CONFIG_SCHED_STACK_END_CHECK=y CONFIG_FUNCTION_TRACER=y -# CONFIG_TRACING_EVENTS_GPIO is not set # CONFIG_RUNTIME_TESTING_MENU is not set CONFIG_DEBUG_WX=y CONFIG_DEBUG_USER=y diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig index 02fa3a41add5..eaab776c4ac2 100644 --- a/arch/arm/configs/aspeed_g5_defconfig +++ b/arch/arm/configs/aspeed_g5_defconfig @@ -248,7 +248,6 @@ CONFIG_PANIC_TIMEOUT=-1 # CONFIG_SCHED_DEBUG is not set CONFIG_SCHED_STACK_END_CHECK=y CONFIG_FUNCTION_TRACER=y -# CONFIG_TRACING_EVENTS_GPIO is not set # CONFIG_RUNTIME_TESTING_MENU is not set CONFIG_DEBUG_WX=y CONFIG_DEBUG_USER=y diff --git a/include/trace/events/gpio.h b/include/trace/events/gpio.h index 5c189a22c489..3aa9fd86d748 100644 --- a/include/trace/events/gpio.h +++ b/include/trace/events/gpio.h @@ -2,10 +2,6 @@ #undef TRACE_SYSTEM #define TRACE_SYSTEM gpio -#ifndef CONFIG_TRACING_EVENTS_GPIO -#define NOTRACE -#endif - #if !defined(_TRACE_GPIO_H) || defined(TRACE_HEADER_MULTI_READ) #define _TRACE_GPIO_H diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index 8bd1d6d001d7..5d965cef6c77 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -774,13 +774,6 @@ config TRACE_EVAL_MAP_FILE If unsure, say N -config TRACING_EVENTS_GPIO - bool "Trace gpio events" - depends on GPIOLIB - default y - help - Enable tracing events for gpio subsystem - config GCOV_PROFILE_FTRACE bool "Enable GCOV profiling on ftrace subsystem" depends on GCOV_KERNEL
gpio tracing was made configurable in 4.4-rc1 (commit ddd70280bf0e ("tracing: gpio: Add Kconfig option for enabling/disabling trace events")). Since then it is the only event type that can be compiled conditionally. Given that there is only little overhead I don't understand the reasoning and I was annoyed more than once that gpio events were not available without recompiling. So drop the Kconfig symbol and make gpio events available unconditionally. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- arch/arm/configs/aspeed_g4_defconfig | 1 - arch/arm/configs/aspeed_g5_defconfig | 1 - include/trace/events/gpio.h | 4 ---- kernel/trace/Kconfig | 7 ------- 4 files changed, 13 deletions(-)