Re: [RFC 1/4] CONFIG_STABLE: Define it

From: Chris Snook
Date: Fri Jul 20 2007 - 07:34:40 EST


Satyam Sharma wrote:
On 7/20/07, Chris Snook <csnook@xxxxxxxxxx> wrote:
Satyam Sharma wrote:
> [ Just cleaning up my inbox, and stumbled across this thread ... ]
>
>
> On 5/31/07, clameter@xxxxxxx <clameter@xxxxxxx> wrote:
>> Introduce CONFIG_STABLE to control checks only useful for development.
>>
>> Signed-off-by: Christoph Lameter <clameter@xxxxxxx>
>> [...]
>> menu "General setup"
>>
>> +config STABLE
>> + bool "Stable kernel"
>> + help
>> + If the kernel is configured to be a stable kernel then various
>> + checks that are only of interest to kernel development will be
>> + omitted.
>> +
>
>
> "A programmer who uses assertions during testing and turns them off
> during production is like a sailor who wears a life vest while drilling
> on shore and takes it off at sea."
> - Tony Hoare
>
>
> Probably you meant to turn off debug _output_ (and not _checks_)
> with this config option? But we already have CONFIG_FOO_DEBUG_BAR
> for those situations ...

There are plenty of validation and debugging features in the kernel that go WAY
beyond mere assertions, often imposing significant overhead (particularly when
you scale up) or creating interfaces you'd never use unless you were doing
kernel development work. You really do want these features completely removed
from production kernels.

As for entire such "development/debugging-related features", most (all, really)
should anyway have their own config options.

They do. With kconfig dependencies, we can ensure that those config options are off when CONFIG_STABLE is set. That way you only have to set one option to ensure that all these expensive checks are disabled.

The point of this is not to remove one-line WARN_ON and BUG_ON checks (though we
might remove a few from fast paths), but rather to disable big chunks of
debugging code that don't implement anything visible to a production workload.

Oh yes, but it's still not clear to me why or how a kernel-wide "CONFIG_STABLE"
or "CONFIG_RELEASE" would help ... what's wrong with finer granularity
"CONFIG_xxx_DEBUG_xxx" kind of knobs?

With kconfig dependencies, we can keep the fine granularity, but not have to spend a half hour digging through the configuration to make sure we have a production-suitable kernel.

-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/