| Summary: | It should be possible to disable kernel features using config fragments | ||
|---|---|---|---|
| Product: | [Documentation] Kernel Development | Reporter: | Jussi Laako <jussi.laako> |
| Component: | kernel-development | Assignee: | Bruce Ashfield <bruce.ashfield> |
| Status: | RESOLVED FIXED | QA Contact: | Costin <costin.c.constantin> |
| Severity: | enhancement | ||
| Priority: | Medium+ | CC: | alexandru.c.georgescu, bruce.ashfield, dvhart, poky.bs.watcher, poky.watcher, richard.purdie, sgw |
| Version: | 1.9 | ||
| Target Milestone: | 2.2 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
|
Description
Jussi Laako
2015-08-18 08:18:02 UTC
I have some old designs (and code for this already) .. it is not a trivial feature to implement. The first pass is really to simply indicate not only that an option didn't make it into the final .config (which we currently do), but to indicate why it didn't make it into the config (i.e. something else selected it). Having the build system do too much and disabling more than it has been explicitly asked to do .. puts too much faith in the system to work. Having complete fragments is still the best approach, since that is what you have to do when disabling things in a hand edited .config. That same logic to detect why an option didn't make it into the final .config can then be extended to optionally do the automatic disabling. Saul: I don't see how this blocks 8177. For now you can just maintain fragments that have all the required options disabled (those that select the one you want off). This is a stretch to get into the fall release (the automatic disabling of dependent options), so I wouldn't count on it being done to free up blockers. At minimum it would be nice to have a build failure if config fragment doesn't have effect on the final configuration. Now if I set CONFIG_SOMETHING=n in config fragment it goes silently through but doesn't have effect. If dependencies are not automatically turned off, it would be nice to get list of options that force the option to be enabled. This is one of the things very cumbersome to go through manually due to dependency trees. Moving this to 2.2, so it can be fully addressed with the kernel symbol / debug enhancements that will happen there. Reducing the time to 10 days as well, since this is partially done and some work is done in other bugs. The current solution for this, is that if a symbol doesn't appear in the final .config, the constraints on the variable are output. i.e. if something selects and option in its Kconfig, you cannot turn it off in the fragment, unless you also disable the option that selected it. We output that information to allow the user to make their own decision on what additional options to disable (or enable). Automatically chasing the dependency tree and changing options that haven't been explicitly set would cause more issues than it solved (i.e. unbootable boards). |