On Sat, Feb 24, 2018 at 03:07:47PM -0800, Darren Hart wrote: > > > On February 24, 2018 3:00:24 PM PST, "Pali Rohár" <pali.rohar@xxxxxxxxx> wrote: > > >And what would happen for existing configs which do not have > >CONFIG_DELL_LAPTOP_EXTRAS yet, but have set e.g. CONFIG_DELL_LAPTOP set > >to Y? > > > >I think we should not break existing distribution configs which already > >have CONFIG_DELL_LAPTOP set to Y or M. > > We have to be able to change *something*. There is no stable CONFIG commitment, and it changes significantly with every release. This makes it much easier for them to get it right going forward. Having been in the distro config business myself, I see this as a very worthwhile trade-off. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. Back at the laptop. People managing distro configs have to validate their desired configs anyway, and we have tools in place to make such changes obvious. If they are using config fragments, they can use scripts/kconfig/merge_config.sh which reports when the final config differs from the input. If they are just using oldconfig, they can use diff and review the changes. The CONFIG space changes a lot, and while I agree we shouldn't make gratuitous changes, I think this one makes a lot of sense. In fact, I think moving moving x86 platform drivers Kconfig to a one level hierarchy by vendor might be a really good way to both make it easier to find things, as well as provide a default set of default=m options, which are only enabled if their menuconfig entry is enabled, simplifying the selection process. If you have an Asus, or a Dell, or a Toshiba, etc. You just select <VENDOR>_EXTRAS and have a pretty chance that it does "the right thing". -- Darren Hart VMware Open Source Technology Center
