Re: [RFC 1/4] CONFIG_STABLE: Define it
On 07/20/2007 12:36 PM, Stefan Richter wrote: +config STABLE + bool "Stable kernel" > > PS: Imagine the headlines at Slashdot, CNET et al when this gets in. I think this really should be called CONFIG_EXTRA_CHECKS. It's a lot clearer what that means... - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
Chris Snook wrote: > There are many different ways you can use it. If I'm writing a configurable > feature, I could make it depend on !CONFIG_STABLE, or I could ifdef my code > out > if CONFIG_STABLE is set, unless a more granular option is also set. The > maintainer of the code that uses the config option has a lot of flexibility, In other words, nobody will ever know what this config option really does. > at least until we start enforcing standards. -- Stefan Richter -=-=-=== -=== =-=-- http://arcgraph.de/sr/ - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
>>> +config STABLE >>> + bool "Stable kernel" PS: Imagine the headlines at Slashdot, CNET et al when this gets in. -- Stefan Richter -=-=-=== -=== =-=-- http://arcgraph.de/sr/ - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
(I missed the original post, hence am replying to te reply...) > 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. >> + Didn't we talk about the wording and the logic some time ago? Your option looks like a magic switch that suddenly improves kernel stability, hence everyone will switch it on. How about this: config BUILD_FOR_RELEASE bool "Build for release" help If the kernel is configured as a release build, various checks that are only of interest to kernel development will be omitted. If unsure, say Y. Or this: config BUILD_FOR_TESTING bool "Build for testing" help If the kernel is configured as a test build, various checks useful for testing of pre-releases will be activated. If unsure, say N. -- Stefan Richter -=-=-=== -=== =-=-- http://arcgraph.de/sr/ - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
Satyam Sharma wrote: On 7/20/07, Chris Snook <[EMAIL PROTECTED]> wrote: 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. Oh, so you mean use this (the negation of this, actually) as a universal kconfig dependency of all other such development/debugging related stuff? Hmm, the name is quite misleading in that case. There are many different ways you can use it. If I'm writing a configurable feature, I could make it depend on !CONFIG_STABLE, or I could ifdef my code out if CONFIG_STABLE is set, unless a more granular option is also set. The maintainer of the code that uses the config option has a lot of flexibility, at least until we start enforcing standards. -- 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On 7/20/07, Chris Snook <[EMAIL PROTECTED]> wrote: 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. Oh, so you mean use this (the negation of this, actually) as a universal kconfig dependency of all other such development/debugging related stuff? Hmm, the name is quite misleading in that case. Anyway, what surprised me was 4/4 in this patchset. Funny that we wouldn't want to corrupt memory / trash hard disks / follow invalid pointers on a developers testbox, but (knowingly) want to do that on a production website running Google.com's website :-) - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
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. 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? - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
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. 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. -- 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
[ 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 ... Satyam - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
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. 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? - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
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. 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. -- 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On 7/20/07, Chris Snook [EMAIL PROTECTED] wrote: 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. Oh, so you mean use this (the negation of this, actually) as a universal kconfig dependency of all other such development/debugging related stuff? Hmm, the name is quite misleading in that case. Anyway, what surprised me was 4/4 in this patchset. Funny that we wouldn't want to corrupt memory / trash hard disks / follow invalid pointers on a developers testbox, but (knowingly) want to do that on a production website running Google.com's website :-) - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
Satyam Sharma wrote: On 7/20/07, Chris Snook [EMAIL PROTECTED] wrote: 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. Oh, so you mean use this (the negation of this, actually) as a universal kconfig dependency of all other such development/debugging related stuff? Hmm, the name is quite misleading in that case. There are many different ways you can use it. If I'm writing a configurable feature, I could make it depend on !CONFIG_STABLE, or I could ifdef my code out if CONFIG_STABLE is set, unless a more granular option is also set. The maintainer of the code that uses the config option has a lot of flexibility, at least until we start enforcing standards. -- 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
(I missed the original post, hence am replying to te reply...) 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. + Didn't we talk about the wording and the logic some time ago? Your option looks like a magic switch that suddenly improves kernel stability, hence everyone will switch it on. How about this: config BUILD_FOR_RELEASE bool Build for release help If the kernel is configured as a release build, various checks that are only of interest to kernel development will be omitted. If unsure, say Y. Or this: config BUILD_FOR_TESTING bool Build for testing help If the kernel is configured as a test build, various checks useful for testing of pre-releases will be activated. If unsure, say N. -- Stefan Richter -=-=-=== -=== =-=-- http://arcgraph.de/sr/ - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
+config STABLE + bool Stable kernel PS: Imagine the headlines at Slashdot, CNET et al when this gets in. -- Stefan Richter -=-=-=== -=== =-=-- http://arcgraph.de/sr/ - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
Chris Snook wrote: There are many different ways you can use it. If I'm writing a configurable feature, I could make it depend on !CONFIG_STABLE, or I could ifdef my code out if CONFIG_STABLE is set, unless a more granular option is also set. The maintainer of the code that uses the config option has a lot of flexibility, In other words, nobody will ever know what this config option really does. at least until we start enforcing standards. -- Stefan Richter -=-=-=== -=== =-=-- http://arcgraph.de/sr/ - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On 07/20/2007 12:36 PM, Stefan Richter wrote: +config STABLE + bool Stable kernel PS: Imagine the headlines at Slashdot, CNET et al when this gets in. I think this really should be called CONFIG_EXTRA_CHECKS. It's a lot clearer what that means... - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
[ 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 ... Satyam - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Fri, Jun 01, 2007 at 04:30:06PM -0400, Dave Jones wrote:
> On Fri, Jun 01, 2007 at 10:22:02PM +0200, Sam Ravnborg wrote:
> > On Fri, Jun 01, 2007 at 02:02:00PM -0400, Dave Jones wrote:
> > > On Thu, May 31, 2007 at 11:30:46PM +0200, Sam Ravnborg wrote:
> > > > > + sym = sym_lookup("DEVEL_KERNEL", 0);
> > > > > + sym->type = S_BOOLEAN;
> > > > > + sym->flags |= SYMBOL_AUTO;
> > > > > + p = getenv("DEVEL_KERNEL");
> > > > > + if (p && atoi(p))
> > > > > + sym_add_default(sym, "y");
> > > > > + else
> > > > > + sym_add_default(sym, "n");
> > > > > +
> > > >
> > > > sym_set_tristate_value(sym, yes);
> > > > else
> > > > sym_set_tristate_value(sym, no);
> > > >
> > > > should do the trick (untested).
> > >
> > > Odd. What's the third state ? Undefined?
> > no, mod, yes
> > Representing: no, module, yes as the three config choices.
>
> Now I'm even more puzzled. Why would 'DEVEL_KERNEL' need
> to be modular ?
The same type is used to represent a boolean and a tristate
within kconfig:
typedef enum tristate {
no, mod, yes
} tristate;
And in the cases where the config symbol is of type 'bool' then
the value 'mod' is not used.
Sam
-
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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Fri, Jun 01, 2007 at 10:22:02PM +0200, Sam Ravnborg wrote:
> On Fri, Jun 01, 2007 at 02:02:00PM -0400, Dave Jones wrote:
> > On Thu, May 31, 2007 at 11:30:46PM +0200, Sam Ravnborg wrote:
> > > > + sym = sym_lookup("DEVEL_KERNEL", 0);
> > > > + sym->type = S_BOOLEAN;
> > > > + sym->flags |= SYMBOL_AUTO;
> > > > + p = getenv("DEVEL_KERNEL");
> > > > + if (p && atoi(p))
> > > > + sym_add_default(sym, "y");
> > > > + else
> > > > + sym_add_default(sym, "n");
> > > > +
> > >
> > > sym_set_tristate_value(sym, yes);
> > > else
> > > sym_set_tristate_value(sym, no);
> > >
> > > should do the trick (untested).
> >
> > Odd. What's the third state ? Undefined?
> no, mod, yes
> Representing: no, module, yes as the three config choices.
Now I'm even more puzzled. Why would 'DEVEL_KERNEL' need
to be modular ?
Dave
--
http://www.codemonkey.org.uk
-
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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
>
> With the following behaviour:
>
> DEVEL_KERNEL = 0 in Makefile:
>
> DEVEL_KERNEL=n in Kconfig
> CONFIG_DEVEL_KERNEL is not set in cpp
>
> DEVEL_KERNEL = 1 in Makefile:
>
> DEVEL_KERNEL=y in Kconfig
> CONFIG_DEVEL_KERNEL is set in cpp
>
> however the above patch doesn't do this correctly and I got bored of
> fiddling with it. Help?
My first try below.
It does the kconfig stuff as expected.
But the CONFIG_KERNEL_DEVEL is NOT updated unless you
touch .config (or in other ways change the config).
I did not see an easy way to fix that - Roman?
I only had to add SYMBOL_VALID as falg to get it working - but it
took me a while to figure out. Somehow all the comments describing the
data structures for kconfig has got lost.
Sam
diff --git a/Makefile b/Makefile
index 562a909..362668c 100644
--- a/Makefile
+++ b/Makefile
@@ -3,6 +3,7 @@ PATCHLEVEL = 6
SUBLEVEL = 22
EXTRAVERSION = -rc3
NAME = Jeff Thinks I Should Change This, But To What?
+KERNEL_DEVEL =
# *DOCUMENTATION*
# To see a list of typical targets execute "make help"
@@ -320,7 +321,7 @@ AFLAGS := -D__ASSEMBLY__
KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
-export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
+export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION KERNEL_DEVEL
export ARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index 8770a5d..5373d58 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -91,6 +91,14 @@ source "init/Kconfig"
menu "Processor type and features"
+config MY_KERNEL_DEVEL
+ bool "Needs Kernel devel"
+ depends on KERNEL_DEVEL
+
+config MY_KERNEL_DEVEL2
+ bool "Do not need kernel devel"
+ depends on !KERNEL_DEVEL
+
source "kernel/time/Kconfig"
config SMP
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index c35dcc5..fb4d5b8 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -68,6 +68,15 @@ void sym_init(void)
if (p)
sym_add_default(sym, p);
+ sym = sym_lookup("KERNEL_DEVEL", 0);
+ sym->type = S_BOOLEAN;
+ sym->flags |= SYMBOL_VALID|SYMBOL_AUTO;
+ p = getenv("KERNEL_DEVEL");
+ if (p && atoi(p))
+ sym_add_default(sym, "y");
+ else
+ sym_add_default(sym, "n");
+
sym = sym_lookup("UNAME_RELEASE", 0);
sym->type = S_STRING;
sym->flags |= SYMBOL_AUTO;
-
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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Fri, Jun 01, 2007 at 02:02:00PM -0400, Dave Jones wrote:
> On Thu, May 31, 2007 at 11:30:46PM +0200, Sam Ravnborg wrote:
> > > +sym = sym_lookup("DEVEL_KERNEL", 0);
> > > +sym->type = S_BOOLEAN;
> > > +sym->flags |= SYMBOL_AUTO;
> > > +p = getenv("DEVEL_KERNEL");
> > > +if (p && atoi(p))
> > > +sym_add_default(sym, "y");
> > > +else
> > > +sym_add_default(sym, "n");
> > > +
> >
> >sym_set_tristate_value(sym, yes);
> >else
> >sym_set_tristate_value(sym, no);
> >
> > should do the trick (untested).
>
> Odd. What's the third state ? Undefined?
no, mod, yes
Representing: no, module, yes as the three config choices.
Sam
-
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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Fri, 1 Jun 2007, Dave Jones wrote: > > Disabling SLUB_DEBUG should only be done for embedded systems. That is why > > the option is in CONFIG_EMBEDDED. > > Something I'd really love to have is a CONFIG option to decide if > slub_debug is set or not by default. The reasoning behind this is that during > development of each Fedora release, I used to leave SLAB_DEBUG=y for > months on end and catch all kinds of nasties. So slub_debug as a boot parameter is not enough. > Now that I've switched it over to using slub, I ended up adding the > ugly patch below, because otherwise, no-one would ever run with > slub_debug and we'd miss out on all those lovely bugs. Oh. No worry. By default slub puts its free pointer in the most dangerous area. In my experience it will bug immediately if there is something wrong. The mode of operations that I had in mind for development was to run until we crash somewhere. Then reboot with slub_debug to get the lovely report on who did it. > (I have 'make release' and 'make debug' targets which enable/disable > this [and other] patches in the Fedora kernel). > > (Patch for illustration only, obviously not for applying). Hummm. I need to think about this one. > Unless someone beats me to it, I'll hack up a CONFIG option around > this. Having that turned on if !CONFIG_STABLE would also be a win I think. Doing so will impair performance testing. Memory use will be changed due to the growth of all the objects etc etc. Generally I think running with slub_debug by default is overkill. Having said that you can do even more if you would run slabinfo -v to validate object from cron. That way you can check up on all slab objects. - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Wed, May 30, 2007 at 05:49:56PM -0700, Christoph Lameter wrote: > On Thu, 31 May 2007, young dave wrote: > > > Hi Christoph, > > > > > Introduce CONFIG_STABLE to control checks only useful for development. > > > > What about control checks only as SLUB_DEBUG is set? > > Debug code is always included in all builds unless it is an embedded > system. Debug code is kept out of the hot path. > > Disabling SLUB_DEBUG should only be done for embedded systems. That is why > the option is in CONFIG_EMBEDDED. Something I'd really love to have is a CONFIG option to decide if slub_debug is set or not by default. The reasoning behind this is that during development of each Fedora release, I used to leave SLAB_DEBUG=y for months on end and catch all kinds of nasties. Now that I've switched it over to using slub, I ended up adding the ugly patch below, because otherwise, no-one would ever run with slub_debug and we'd miss out on all those lovely bugs. (I have 'make release' and 'make debug' targets which enable/disable this [and other] patches in the Fedora kernel). (Patch for illustration only, obviously not for applying). Unless someone beats me to it, I'll hack up a CONFIG option around this. Having that turned on if !CONFIG_STABLE would also be a win I think. Dave --- linux-2.6/mm/slub.c~2007-05-27 21:48:42.0 -0400 +++ linux-2.6/mm/slub.c 2007-05-27 21:51:22.0 -0400 @@ -323,7 +323,7 @@ static inline int slab_index(void *p, st /* * Debug settings: */ -static int slub_debug; +static int slub_debug = DEBUG_DEFAULT_FLAGS; static char *slub_debug_slabs; -- http://www.codemonkey.org.uk - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Thu, May 31, 2007 at 11:30:46PM +0200, Sam Ravnborg wrote:
> > + sym = sym_lookup("DEVEL_KERNEL", 0);
> > + sym->type = S_BOOLEAN;
> > + sym->flags |= SYMBOL_AUTO;
> > + p = getenv("DEVEL_KERNEL");
> > + if (p && atoi(p))
> > + sym_add_default(sym, "y");
> > + else
> > + sym_add_default(sym, "n");
> > +
>
> sym_set_tristate_value(sym, yes);
> else
> sym_set_tristate_value(sym, no);
>
> should do the trick (untested).
Odd. What's the third state ? Undefined?
Dave
--
http://www.codemonkey.org.uk
-
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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Thu, May 31, 2007 at 11:30:46PM +0200, Sam Ravnborg wrote: + sym = sym_lookup(DEVEL_KERNEL, 0); + sym-type = S_BOOLEAN; + sym-flags |= SYMBOL_AUTO; + p = getenv(DEVEL_KERNEL); + if (p atoi(p)) + sym_add_default(sym, y); + else + sym_add_default(sym, n); + sym_set_tristate_value(sym, yes); else sym_set_tristate_value(sym, no); should do the trick (untested). Odd. What's the third state ? Undefined? Dave -- http://www.codemonkey.org.uk - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Wed, May 30, 2007 at 05:49:56PM -0700, Christoph Lameter wrote: On Thu, 31 May 2007, young dave wrote: Hi Christoph, Introduce CONFIG_STABLE to control checks only useful for development. What about control checks only as SLUB_DEBUG is set? Debug code is always included in all builds unless it is an embedded system. Debug code is kept out of the hot path. Disabling SLUB_DEBUG should only be done for embedded systems. That is why the option is in CONFIG_EMBEDDED. Something I'd really love to have is a CONFIG option to decide if slub_debug is set or not by default. The reasoning behind this is that during development of each Fedora release, I used to leave SLAB_DEBUG=y for months on end and catch all kinds of nasties. Now that I've switched it over to using slub, I ended up adding the ugly patch below, because otherwise, no-one would ever run with slub_debug and we'd miss out on all those lovely bugs. (I have 'make release' and 'make debug' targets which enable/disable this [and other] patches in the Fedora kernel). (Patch for illustration only, obviously not for applying). Unless someone beats me to it, I'll hack up a CONFIG option around this. Having that turned on if !CONFIG_STABLE would also be a win I think. Dave --- linux-2.6/mm/slub.c~2007-05-27 21:48:42.0 -0400 +++ linux-2.6/mm/slub.c 2007-05-27 21:51:22.0 -0400 @@ -323,7 +323,7 @@ static inline int slab_index(void *p, st /* * Debug settings: */ -static int slub_debug; +static int slub_debug = DEBUG_DEFAULT_FLAGS; static char *slub_debug_slabs; -- http://www.codemonkey.org.uk - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Fri, 1 Jun 2007, Dave Jones wrote: Disabling SLUB_DEBUG should only be done for embedded systems. That is why the option is in CONFIG_EMBEDDED. Something I'd really love to have is a CONFIG option to decide if slub_debug is set or not by default. The reasoning behind this is that during development of each Fedora release, I used to leave SLAB_DEBUG=y for months on end and catch all kinds of nasties. So slub_debug as a boot parameter is not enough. Now that I've switched it over to using slub, I ended up adding the ugly patch below, because otherwise, no-one would ever run with slub_debug and we'd miss out on all those lovely bugs. Oh. No worry. By default slub puts its free pointer in the most dangerous area. In my experience it will bug immediately if there is something wrong. The mode of operations that I had in mind for development was to run until we crash somewhere. Then reboot with slub_debug to get the lovely report on who did it. (I have 'make release' and 'make debug' targets which enable/disable this [and other] patches in the Fedora kernel). (Patch for illustration only, obviously not for applying). Hummm. I need to think about this one. Unless someone beats me to it, I'll hack up a CONFIG option around this. Having that turned on if !CONFIG_STABLE would also be a win I think. Doing so will impair performance testing. Memory use will be changed due to the growth of all the objects etc etc. Generally I think running with slub_debug by default is overkill. Having said that you can do even more if you would run slabinfo -v to validate object from cron. That way you can check up on all slab objects. - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Fri, Jun 01, 2007 at 02:02:00PM -0400, Dave Jones wrote: On Thu, May 31, 2007 at 11:30:46PM +0200, Sam Ravnborg wrote: +sym = sym_lookup(DEVEL_KERNEL, 0); +sym-type = S_BOOLEAN; +sym-flags |= SYMBOL_AUTO; +p = getenv(DEVEL_KERNEL); +if (p atoi(p)) +sym_add_default(sym, y); +else +sym_add_default(sym, n); + sym_set_tristate_value(sym, yes); else sym_set_tristate_value(sym, no); should do the trick (untested). Odd. What's the third state ? Undefined? no, mod, yes Representing: no, module, yes as the three config choices. Sam - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
With the following behaviour: DEVEL_KERNEL = 0 in Makefile: DEVEL_KERNEL=n in Kconfig CONFIG_DEVEL_KERNEL is not set in cpp DEVEL_KERNEL = 1 in Makefile: DEVEL_KERNEL=y in Kconfig CONFIG_DEVEL_KERNEL is set in cpp however the above patch doesn't do this correctly and I got bored of fiddling with it. Help? My first try below. It does the kconfig stuff as expected. But the CONFIG_KERNEL_DEVEL is NOT updated unless you touch .config (or in other ways change the config). I did not see an easy way to fix that - Roman? I only had to add SYMBOL_VALID as falg to get it working - but it took me a while to figure out. Somehow all the comments describing the data structures for kconfig has got lost. Sam diff --git a/Makefile b/Makefile index 562a909..362668c 100644 --- a/Makefile +++ b/Makefile @@ -3,6 +3,7 @@ PATCHLEVEL = 6 SUBLEVEL = 22 EXTRAVERSION = -rc3 NAME = Jeff Thinks I Should Change This, But To What? +KERNEL_DEVEL = # *DOCUMENTATION* # To see a list of typical targets execute make help @@ -320,7 +321,7 @@ AFLAGS := -D__ASSEMBLY__ KERNELRELEASE = $(shell cat include/config/kernel.release 2 /dev/null) KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) -export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION +export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION KERNEL_DEVEL export ARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig index 8770a5d..5373d58 100644 --- a/arch/i386/Kconfig +++ b/arch/i386/Kconfig @@ -91,6 +91,14 @@ source init/Kconfig menu Processor type and features +config MY_KERNEL_DEVEL + bool Needs Kernel devel + depends on KERNEL_DEVEL + +config MY_KERNEL_DEVEL2 + bool Do not need kernel devel + depends on !KERNEL_DEVEL + source kernel/time/Kconfig config SMP diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c index c35dcc5..fb4d5b8 100644 --- a/scripts/kconfig/symbol.c +++ b/scripts/kconfig/symbol.c @@ -68,6 +68,15 @@ void sym_init(void) if (p) sym_add_default(sym, p); + sym = sym_lookup(KERNEL_DEVEL, 0); + sym-type = S_BOOLEAN; + sym-flags |= SYMBOL_VALID|SYMBOL_AUTO; + p = getenv(KERNEL_DEVEL); + if (p atoi(p)) + sym_add_default(sym, y); + else + sym_add_default(sym, n); + sym = sym_lookup(UNAME_RELEASE, 0); sym-type = S_STRING; sym-flags |= SYMBOL_AUTO; - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Fri, Jun 01, 2007 at 10:22:02PM +0200, Sam Ravnborg wrote: On Fri, Jun 01, 2007 at 02:02:00PM -0400, Dave Jones wrote: On Thu, May 31, 2007 at 11:30:46PM +0200, Sam Ravnborg wrote: + sym = sym_lookup(DEVEL_KERNEL, 0); + sym-type = S_BOOLEAN; + sym-flags |= SYMBOL_AUTO; + p = getenv(DEVEL_KERNEL); + if (p atoi(p)) + sym_add_default(sym, y); + else + sym_add_default(sym, n); + sym_set_tristate_value(sym, yes); else sym_set_tristate_value(sym, no); should do the trick (untested). Odd. What's the third state ? Undefined? no, mod, yes Representing: no, module, yes as the three config choices. Now I'm even more puzzled. Why would 'DEVEL_KERNEL' need to be modular ? Dave -- http://www.codemonkey.org.uk - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Fri, Jun 01, 2007 at 04:30:06PM -0400, Dave Jones wrote:
On Fri, Jun 01, 2007 at 10:22:02PM +0200, Sam Ravnborg wrote:
On Fri, Jun 01, 2007 at 02:02:00PM -0400, Dave Jones wrote:
On Thu, May 31, 2007 at 11:30:46PM +0200, Sam Ravnborg wrote:
+ sym = sym_lookup(DEVEL_KERNEL, 0);
+ sym-type = S_BOOLEAN;
+ sym-flags |= SYMBOL_AUTO;
+ p = getenv(DEVEL_KERNEL);
+ if (p atoi(p))
+ sym_add_default(sym, y);
+ else
+ sym_add_default(sym, n);
+
sym_set_tristate_value(sym, yes);
else
sym_set_tristate_value(sym, no);
should do the trick (untested).
Odd. What's the third state ? Undefined?
no, mod, yes
Representing: no, module, yes as the three config choices.
Now I'm even more puzzled. Why would 'DEVEL_KERNEL' need
to be modular ?
The same type is used to represent a boolean and a tristate
within kconfig:
typedef enum tristate {
no, mod, yes
} tristate;
And in the cases where the config symbol is of type 'bool' then
the value 'mod' is not used.
Sam
-
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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
>
> So something like this:
>
> diff -puN Makefile~a Makefile
> --- a/Makefile~a
> +++ a/Makefile
> @@ -3,6 +3,7 @@ PATCHLEVEL = 6
> SUBLEVEL = 22
> EXTRAVERSION = -rc3
> NAME = Jeff Thinks I Should Change This, But To What?
> +DEVEL_KERNEL = 1
Could we name this: KERNELDEVEL to fit with current naming convention?
Alternative: KERNEL_DEVEL
Maybe a little comment that this is mirrored as a CONFIG_ symbol?
>
> # *DOCUMENTATION*
> # To see a list of typical targets execute "make help"
> @@ -320,7 +321,7 @@ AFLAGS := -D__ASSEMBLY__
> KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
> KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
>
> -export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
> +export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION DEVEL_KERNEL
> export ARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
> export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE
> export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
> diff -puN scripts/kconfig/symbol.c~a scripts/kconfig/symbol.c
> --- a/scripts/kconfig/symbol.c~a
> +++ a/scripts/kconfig/symbol.c
> @@ -68,6 +68,15 @@ void sym_init(void)
> if (p)
> sym_add_default(sym, p);
>
> + sym = sym_lookup("DEVEL_KERNEL", 0);
> + sym->type = S_BOOLEAN;
> + sym->flags |= SYMBOL_AUTO;
> + p = getenv("DEVEL_KERNEL");
> + if (p && atoi(p))
> + sym_add_default(sym, "y");
> + else
> + sym_add_default(sym, "n");
> +
sym_set_tristate_value(sym, yes);
else
sym_set_tristate_value(sym, no);
should do the trick (untested).
Sam
-
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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Thu, 31 May 2007, Andrew Morton wrote: > however the above patch doesn't do this correctly and I got bored of > fiddling with it. Help? Will get something like what you described into the next release if no one else has anything to add. - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Wed, 30 May 2007 17:20:48 -0700
[EMAIL PROTECTED] wrote:
> Introduce CONFIG_STABLE to control checks only useful for development.
>
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
>
> ---
> init/Kconfig |7 +++
> 1 file changed, 7 insertions(+)
>
> Index: slub/init/Kconfig
> ===
> --- slub.orig/init/Kconfig2007-05-30 16:35:05.0 -0700
> +++ slub/init/Kconfig 2007-05-30 16:35:45.0 -0700
> @@ -65,6 +65,13 @@ endmenu
>
> 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.
> +
> config LOCALVERSION
> string "Local version - append to kernel release"
> help
OK, but I think it'd be better if this knob was at line 6 of ./Makefile so
that Linus remembers to turn it on and off at appropriate times. Also, I
suspect that we want it available within Kconfig expressions as well as
within cpp expressions.
So something like this:
diff -puN Makefile~a Makefile
--- a/Makefile~a
+++ a/Makefile
@@ -3,6 +3,7 @@ PATCHLEVEL = 6
SUBLEVEL = 22
EXTRAVERSION = -rc3
NAME = Jeff Thinks I Should Change This, But To What?
+DEVEL_KERNEL = 1
# *DOCUMENTATION*
# To see a list of typical targets execute "make help"
@@ -320,7 +321,7 @@ AFLAGS := -D__ASSEMBLY__
KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
-export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
+export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION DEVEL_KERNEL
export ARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
diff -puN scripts/kconfig/symbol.c~a scripts/kconfig/symbol.c
--- a/scripts/kconfig/symbol.c~a
+++ a/scripts/kconfig/symbol.c
@@ -68,6 +68,15 @@ void sym_init(void)
if (p)
sym_add_default(sym, p);
+ sym = sym_lookup("DEVEL_KERNEL", 0);
+ sym->type = S_BOOLEAN;
+ sym->flags |= SYMBOL_AUTO;
+ p = getenv("DEVEL_KERNEL");
+ if (p && atoi(p))
+ sym_add_default(sym, "y");
+ else
+ sym_add_default(sym, "n");
+
sym = sym_lookup("UNAME_RELEASE", 0);
sym->type = S_STRING;
sym->flags |= SYMBOL_AUTO;
_
With the following behaviour:
DEVEL_KERNEL = 0 in Makefile:
DEVEL_KERNEL=n in Kconfig
CONFIG_DEVEL_KERNEL is not set in cpp
DEVEL_KERNEL = 1 in Makefile:
DEVEL_KERNEL=y in Kconfig
CONFIG_DEVEL_KERNEL is set in cpp
however the above patch doesn't do this correctly and I got bored of
fiddling with it. Help?
-
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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
>> menu "General setup" >> >> +config STABLE >> +bool "Stable kernel" [...] > a) Why in Kconfig, why not in Makefile? > > b) Of course nobody wants STABLE=n. :-) How about: > > config RELEASE > bool "Build for release" > help > If the kernel is declared as a release build here, then > various checks that are only of interest to kernel development > will be omitted. PS: Also, it could be reversed (e.g. config TESTBUILD) and put into the Kernel Hacking submenu. > c) A drawback of this general option is, it's hard to tell what will be > omitted in particular. -- Stefan Richter -=-=-=== -=-= = http://arcgraph.de/sr/ - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
From: Stefan Richter <[EMAIL PROTECTED]> Date: Thu, 31 May 2007 10:54:36 +0200 > b) Of course nobody wants STABLE=n. :-) How about: > > config RELEASE > bool "Build for release" > help > If the kernel is declared as a release build here, then > various checks that are only of interest to kernel development > will be omitted. Agreed :-) > > c) A drawback of this general option is, it's hard to tell what will be >omitted in particular. In that sense it is similar to EMBEDDED, but I still think there is high value to this, I can already think of several things I want to put under this which are only noise I want to see during development periods. - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
> --- slub.orig/init/Kconfig2007-05-30 16:35:05.0 -0700 > +++ slub/init/Kconfig 2007-05-30 16:35:45.0 -0700 > @@ -65,6 +65,13 @@ endmenu > > 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. > + > config LOCALVERSION > string "Local version - append to kernel release" > help a) Why in Kconfig, why not in Makefile? b) Of course nobody wants STABLE=n. :-) How about: config RELEASE bool "Build for release" help If the kernel is declared as a release build here, then various checks that are only of interest to kernel development will be omitted. c) A drawback of this general option is, it's hard to tell what will be omitted in particular. -- Stefan Richter -=-=-=== -=-= = http://arcgraph.de/sr/ - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
--- slub.orig/init/Kconfig2007-05-30 16:35:05.0 -0700 +++ slub/init/Kconfig 2007-05-30 16:35:45.0 -0700 @@ -65,6 +65,13 @@ endmenu 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. + config LOCALVERSION string Local version - append to kernel release help a) Why in Kconfig, why not in Makefile? b) Of course nobody wants STABLE=n. :-) How about: config RELEASE bool Build for release help If the kernel is declared as a release build here, then various checks that are only of interest to kernel development will be omitted. c) A drawback of this general option is, it's hard to tell what will be omitted in particular. -- Stefan Richter -=-=-=== -=-= = http://arcgraph.de/sr/ - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
From: Stefan Richter [EMAIL PROTECTED] Date: Thu, 31 May 2007 10:54:36 +0200 b) Of course nobody wants STABLE=n. :-) How about: config RELEASE bool Build for release help If the kernel is declared as a release build here, then various checks that are only of interest to kernel development will be omitted. Agreed :-) c) A drawback of this general option is, it's hard to tell what will be omitted in particular. In that sense it is similar to EMBEDDED, but I still think there is high value to this, I can already think of several things I want to put under this which are only noise I want to see during development periods. - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
menu General setup +config STABLE +bool Stable kernel [...] a) Why in Kconfig, why not in Makefile? b) Of course nobody wants STABLE=n. :-) How about: config RELEASE bool Build for release help If the kernel is declared as a release build here, then various checks that are only of interest to kernel development will be omitted. PS: Also, it could be reversed (e.g. config TESTBUILD) and put into the Kernel Hacking submenu. c) A drawback of this general option is, it's hard to tell what will be omitted in particular. -- Stefan Richter -=-=-=== -=-= = http://arcgraph.de/sr/ - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Wed, 30 May 2007 17:20:48 -0700 [EMAIL PROTECTED] wrote: Introduce CONFIG_STABLE to control checks only useful for development. Signed-off-by: Christoph Lameter [EMAIL PROTECTED] --- init/Kconfig |7 +++ 1 file changed, 7 insertions(+) Index: slub/init/Kconfig === --- slub.orig/init/Kconfig2007-05-30 16:35:05.0 -0700 +++ slub/init/Kconfig 2007-05-30 16:35:45.0 -0700 @@ -65,6 +65,13 @@ endmenu 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. + config LOCALVERSION string Local version - append to kernel release help OK, but I think it'd be better if this knob was at line 6 of ./Makefile so that Linus remembers to turn it on and off at appropriate times. Also, I suspect that we want it available within Kconfig expressions as well as within cpp expressions. So something like this: diff -puN Makefile~a Makefile --- a/Makefile~a +++ a/Makefile @@ -3,6 +3,7 @@ PATCHLEVEL = 6 SUBLEVEL = 22 EXTRAVERSION = -rc3 NAME = Jeff Thinks I Should Change This, But To What? +DEVEL_KERNEL = 1 # *DOCUMENTATION* # To see a list of typical targets execute make help @@ -320,7 +321,7 @@ AFLAGS := -D__ASSEMBLY__ KERNELRELEASE = $(shell cat include/config/kernel.release 2 /dev/null) KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) -export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION +export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION DEVEL_KERNEL export ARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS diff -puN scripts/kconfig/symbol.c~a scripts/kconfig/symbol.c --- a/scripts/kconfig/symbol.c~a +++ a/scripts/kconfig/symbol.c @@ -68,6 +68,15 @@ void sym_init(void) if (p) sym_add_default(sym, p); + sym = sym_lookup(DEVEL_KERNEL, 0); + sym-type = S_BOOLEAN; + sym-flags |= SYMBOL_AUTO; + p = getenv(DEVEL_KERNEL); + if (p atoi(p)) + sym_add_default(sym, y); + else + sym_add_default(sym, n); + sym = sym_lookup(UNAME_RELEASE, 0); sym-type = S_STRING; sym-flags |= SYMBOL_AUTO; _ With the following behaviour: DEVEL_KERNEL = 0 in Makefile: DEVEL_KERNEL=n in Kconfig CONFIG_DEVEL_KERNEL is not set in cpp DEVEL_KERNEL = 1 in Makefile: DEVEL_KERNEL=y in Kconfig CONFIG_DEVEL_KERNEL is set in cpp however the above patch doesn't do this correctly and I got bored of fiddling with it. Help? - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Thu, 31 May 2007, Andrew Morton wrote: however the above patch doesn't do this correctly and I got bored of fiddling with it. Help? Will get something like what you described into the next release if no one else has anything to add. - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
So something like this: diff -puN Makefile~a Makefile --- a/Makefile~a +++ a/Makefile @@ -3,6 +3,7 @@ PATCHLEVEL = 6 SUBLEVEL = 22 EXTRAVERSION = -rc3 NAME = Jeff Thinks I Should Change This, But To What? +DEVEL_KERNEL = 1 Could we name this: KERNELDEVEL to fit with current naming convention? Alternative: KERNEL_DEVEL Maybe a little comment that this is mirrored as a CONFIG_ symbol? # *DOCUMENTATION* # To see a list of typical targets execute make help @@ -320,7 +321,7 @@ AFLAGS := -D__ASSEMBLY__ KERNELRELEASE = $(shell cat include/config/kernel.release 2 /dev/null) KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) -export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION +export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION DEVEL_KERNEL export ARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS diff -puN scripts/kconfig/symbol.c~a scripts/kconfig/symbol.c --- a/scripts/kconfig/symbol.c~a +++ a/scripts/kconfig/symbol.c @@ -68,6 +68,15 @@ void sym_init(void) if (p) sym_add_default(sym, p); + sym = sym_lookup(DEVEL_KERNEL, 0); + sym-type = S_BOOLEAN; + sym-flags |= SYMBOL_AUTO; + p = getenv(DEVEL_KERNEL); + if (p atoi(p)) + sym_add_default(sym, y); + else + sym_add_default(sym, n); + sym_set_tristate_value(sym, yes); else sym_set_tristate_value(sym, no); should do the trick (untested). Sam - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Thu, 31 May 2007, young dave wrote: > Hi Christoph, > > > Introduce CONFIG_STABLE to control checks only useful for development. > > What about control checks only as SLUB_DEBUG is set? Debug code is always included in all builds unless it is an embedded system. Debug code is kept out of the hot path. Disabling SLUB_DEBUG should only be done for embedded systems. That is why the option is in CONFIG_EMBEDDED. - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
Hi Christoph, Introduce CONFIG_STABLE to control checks only useful for development. What about control checks only as SLUB_DEBUG is set? Regards dave - 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/
[RFC 1/4] CONFIG_STABLE: Define it
Introduce CONFIG_STABLE to control checks only useful for development. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- init/Kconfig |7 +++ 1 file changed, 7 insertions(+) Index: slub/init/Kconfig === --- slub.orig/init/Kconfig 2007-05-30 16:35:05.0 -0700 +++ slub/init/Kconfig 2007-05-30 16:35:45.0 -0700 @@ -65,6 +65,13 @@ endmenu 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. + config LOCALVERSION string "Local version - append to kernel release" help -- - 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/
[RFC 1/4] CONFIG_STABLE: Define it
Introduce CONFIG_STABLE to control checks only useful for development. Signed-off-by: Christoph Lameter [EMAIL PROTECTED] --- init/Kconfig |7 +++ 1 file changed, 7 insertions(+) Index: slub/init/Kconfig === --- slub.orig/init/Kconfig 2007-05-30 16:35:05.0 -0700 +++ slub/init/Kconfig 2007-05-30 16:35:45.0 -0700 @@ -65,6 +65,13 @@ endmenu 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. + config LOCALVERSION string Local version - append to kernel release help -- - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
Hi Christoph, Introduce CONFIG_STABLE to control checks only useful for development. What about control checks only as SLUB_DEBUG is set? Regards dave - 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/
Re: [RFC 1/4] CONFIG_STABLE: Define it
On Thu, 31 May 2007, young dave wrote: Hi Christoph, Introduce CONFIG_STABLE to control checks only useful for development. What about control checks only as SLUB_DEBUG is set? Debug code is always included in all builds unless it is an embedded system. Debug code is kept out of the hot path. Disabling SLUB_DEBUG should only be done for embedded systems. That is why the option is in CONFIG_EMBEDDED. - 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/
