net: trivial MLX4_DEBUG dependency fix.
PATCH 1/1 net: trivial MLX4_DEBUG dependency fix.
First SLUB_DEBUG, and now this..
CONFIG_MLX4_DEBUG works out to a def_bool y for those that have CONFIG_EMBEDDED set. Make it depend on MLX4_CORE..
I'll let someone else wonder why debugging output is default enabled, this seems to be a worrying trend as of late.
--
drivers/net/Kconfig +1 -0
@@ -2500,6 +2500,7 @@ config MLX4_CORE config MLX4_DEBUG bool "Verbose debugging output" if (MLX4_CORE && EMBEDDED) + depends on MLX4_CORE default y ---help--- This option causes debugging code to be compiled into the
Roland Dreier
AppliedQuoted 2 lines
CONFIG_MLX4_DEBUGworks out to adef_booly for those that haveCONFIG_EMBEDDEDset. Make it depend onMLX4_CORE..
Thanks, applied... (by the way, this bug just results in an extraneous CONFIG variable being defined, right? There's no further breakage -- or am I misunderstanding the situation?)
Quoted 2 lines
I'll let someone else wonder why debugging output is default enabled, this seems to be a worrying trend as of late.
Actually this option just controls whether to build the debugging output at all. The output is controlled at runtime with a module parameter (which can be changed via sysfs after the module is loaded), and the output defaults to off.
The reason why I want building the debugging stuff to default to y is so that distros automatically build modules with debugging enabled. Otherwise it's a pain to try and gather info from someone who has problems with a kernel they didn't build.
Thanks,
Roland
Hi,
Quoted 6 lines · Roland Dreier
Quoted 2 lines
CONFIG_MLX4_DEBUGworks out to adef_booly for those that haveCONFIG_EMBEDDEDset. Make it depend onMLX4_CORE..Thanks, applied... (by the way, this bug just results in an extraneous CONFIG variable being defined, right? There's no further breakage -- or am I misunderstanding the situation?)
Yeah, it won't cause any build breakage. It doesn't cause anything to even get _built_ actually, because of the way this config option is used directly in the .h and .c sources in drivers/net/mlx4/ (which is itself compiled only when MLX4_CORE=y or m), and not in a Makefile.
Quoted 8 lines
Quoted 2 lines
I'll let someone else wonder why debugging output is default enabled, this seems to be a worrying trend as of late.
Actually this option just controls whether to build the debugging output at all. The output is controlled at runtime with a module parameter (which can be changed via sysfs after the module is loaded), and the output defaults to off.
Quoted 4 lines
The reason why I want building the debugging stuff to default to y is so that distros automatically build modules with debugging enabled. Otherwise it's a pain to try and gather info from someone who has problems with a kernel they didn't build.
IMHO default configs must be aimed at production usage scenarios, so are better off without debugging enabled by default. Except if the driver is really new / EXPERIMENTAL where the goal is to get it tested out by all users asap (and no production systems would be using it anyway).
Just my 2 paise,
Satyam
Quoted 7 lines · Roland Dreier
Quoted 2 lines
CONFIG_MLX4_DEBUGworks out to adef_booly for those that haveCONFIG_EMBEDDEDset. Make it depend onMLX4_CORE..Thanks, applied... (by the way, this bug just results in an extraneous CONFIG variable being defined, right? There's no further breakage -- or am I misunderstanding the situation?)
Correct, there was no real breakage, just the extraneous variable. SLUB_DEBUG had the same symptoms, which is why I referenced it ;-)
Quoted 8 lines
Quoted 2 lines
I'll let someone else wonder why debugging output is default enabled, this seems to be a worrying trend as of late.
Actually this option just controls whether to build the debugging output at all. The output is controlled at runtime with a module parameter (which can be changed via sysfs after the module is loaded), and the output defaults to off.
Quoted 5 lines
The reason why I want building the debugging stuff to default to y is so that distros automatically build modules with debugging enabled. Otherwise it's a pain to try and gather info from someone who has problems with a kernel they didn't build.
That's more reasonable at least. Thanks for the clarification.
Quoted 5 lines
IMHO default configs must be aimed at production usage scenarios, so are better off without debugging enabled by default. Except if the driver is really new / EXPERIMENTAL where the goal is to get it tested out by all users asap (and no production systems would be using it anyway).
I agree, but I would hope that MLX4_DEBUG *is* enabled in production. It doesn't print anything or introduce any measurable overhead except for slightly larger code size unless the debug level is explicitly increased, so the only reason to turn it off is if a few bytes of code makes a big difference to you (hence making it selectable only if EMBEDDED is selected).