On Wed, Dec 7, 2016 at 1:07 PM, Arnd Bergmann <[email protected]> wrote: > On Wednesday, December 7, 2016 12:41:29 PM CET Bartlomiej Zolnierkiewicz > wrote: >> >> On Tuesday, December 06, 2016 11:03:34 AM Olof Johansson wrote: >> > On Tue, Dec 6, 2016 at 4:38 AM, Bartlomiej Zolnierkiewicz >> > <[email protected]> wrote: >> > > Hi, >> > > >> > > This RFC patchset starts convertion of ARM defconfigs to use kconfig >> > > fragments and dynamically generate defconfigs. The goals of this >> > > work are to: >> > >> > You don't provide any motivation as to why this is better. As far as I >> >> Benefits are: >> >> - no code duplication (this initial patchset alone removes ~1700 lines >> from defconfigs without any change in functionality) > > This may be interesting
Management of the fragments is the big headache here. I haven't seen any system that does it well downstream either in a way that scales as far as we'd need it to. >> - prevention of "multi" defconfigs (i.e. multi_v7_defconfig) going out >> of sync with "SoC-family" ones (i.e. exynos_defconfig) - there will >> be just one place to update when changing things > > I'm not convinced this is worthwhile: in a lot of cases, the soc-specific > configs want to enable things built-in, while the more generic ones > tend to use loadable modules. Agreed. >> - possibility to add support for more optimized defconfigs (i.e. board >> specific ones) in the future without duplicating the code > > I'd prefer seeing fewer top-level options than more of them, so > this doesn't really help. > >> - making it easier to define arch specific parts of defconfigs in >> the future if we decide on doing it (i.e. we may want to enable >> things like CONFIG_SYSVIPC for all defconfigs) > > The example you give is for something that should be decided > in architecture-independent Kconfig language rather than > per architecture, and that won't require fragments. > >> > am concerned it'll just be a mess. >> > >> > So: >> > >> > Nack. So much nack. I really don't want to see a proliferation of >> > config fragments like this. >> > >> > I had a feeling it was a bad idea to pick up that one line config >> > fragment before, since it opened the door for this kind of mess. >> >> Like I said in the cover-letter I'm not satisfied with the current >> patches and they have much room for improvement. >> >> However I see that you don't like the idea itself... > > I do think that there is some room for more config fragments in > mainline, but not most of the patches you have here. Some areas > that I think would benefit from fragments are: > > - architecture level selection: v6/v6k/v7/v7ve/v8 could have a > common defconfig file that starts out with all v6+ enabled, > but then having fragments that disable the older architectures > and platforms using them while turning on features that are only > available on newer architectures > > - A "debug" fragment would be nice, to turn on common options that > add a lot of useful runtime checks at the expense of performance > or code size. Hmm, some of these might work but several useful debug options (in particular DEBUG_LL for early errors) are per-system/platform. > - A "distro" fragment that turns on all loadable modules that are > enabled by common distributions (e.g. two or more of > debian/fedora/opensuse/gentoo), to let you build a drop-in > replacement kernel for a shipping distro. This would also allow > the distros to strip their own config files and just specify > whatever differs from the others. Keeping this in sync with the distro kernel could be a bit awkward (and possibly churny). -Olof
