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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Satyam Sharma wrote:
On 7/20/07, Chris Snook <[email protected]> wrote:
Satyam Sharma wrote:
> [ Just cleaning up my inbox, and stumbled across this thread ... ]
>
>
> On 5/31/07, [email protected] <[email protected]> wrote:
>> Introduce CONFIG_STABLE to control checks only useful for development.
>>
>> Signed-off-by: Christoph Lameter <[email protected]>
>> [...]
>>  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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux