8179 2015-08-18 08:18:02 +0000 It should be possible to disable kernel features using config fragments 2016-09-16 19:51:55 +0000 1 1 9 Documentation Kernel Development kernel-development 1.9 x86 Multiple RESOLVED FIXED Medium+ enhancement 2.2 M3 1 jussi.laako bruce.ashfield alexandru.c.georgescu bruce.ashfield dvhart poky.bs.watcher poky.watcher richard.purdie sgw costin.c.constantin --- --- Yes (doc changes required) oldest_to_newest 53177 0 jussi.laako 2015-08-18 08:18:02 +0000 It should be possible to disable kernel features originating for example from the default BSP config using config fragments. Also when asking to disable for example CONFIG_DEBUG_KERNEL the build system should traverse config option dependency tree and disable also all options that depend on the specified config option. Otherwise it becomes a daunting task to hunt down and maintain also disabling of all the options unrelated to the original goal but which happen to depend on the given option for some reason. Same dependency traversal should also work when asking for some option to be enabled. Now it doesn't always work. For example asking to enable a certain USB serial driver in a config fragment doesn't work if the BSP doesn't happen to have generic CONFIG_USB_SERIAL option enabled. Some BSPs do have it, some don't. There is a library available for dealing with Kconfig options which can be used to implement this. 53190 1 bruce.ashfield 2015-08-18 14:43:21 +0000 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. 53206 2 jussi.laako 2015-08-19 08:00:44 +0000 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. 60244 3 bruce.ashfield 2016-03-21 23:27:52 +0000 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. 66267 4 bruce.ashfield 2016-09-16 19:51:55 +0000 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).