On Tue, Oct 25, 2016 at 02:14:08PM -0400, Don Zickus wrote: > On Tue, Oct 25, 2016 at 10:46:00AM -0700, Laura Abbott wrote: > > The Fedora kernel has had roughly the same system for generating > > the kernel configuration for a very long time. There are a series > > of files listing configuration choices (CONFIG_FOO=y, CONFIG_FOO > > is not set etc.) that get combined to generate the final config > > files. This has gotten unsustainable for several reasons: > > > > - When the system was first introduced, the only supported > > arches were x86_32 and x86_64. Fedora now supports enough > > other arches that we have a config-$arch-generic in addition to > > config-generic > > - It's difficult to tell what is actually enabled since > > there are several layers of configuration combining (I have to > > look at config-generic, then config-$arch-generic, then > > the final config-$specific file to see what the option actually > > is) > > - Keeping the files organized requires manual work and pruning > > > > I've been thinking about alternatives to the existing config > > generation. One proposal was to take advantage of the upstream > > kernel now supporting config fragments and keep some part of > > the fedora configuration upstream. This would have the disadvantage > > of requiring the configuration to be kept in sync with upstream. > > > > Another option is to switch to a system of generation where > > each configuration option is kept in a separate file. There > > is no sorting or organization necessary. This would result > > in a lot of small files for all the arches Fedora supports though. > > Hi Laura, > > Just to throw it out there, RHEL has been using the one option per file > mechanism for years now with success. Minimizes the maintenance and > conflicts. ( I know you already know that, just wanted to publicly state > that). > > The volume of files is large, but it is hidden away and you only package the > resulting kernel.config files into the src.rpm.
I'm quite fond of the was things were done in el7 too, but I'm biased, since I'm the one that implemented it. ;) Honestly though, part of the reason for doing it was because those various stacked config hunks were *terrible* to deal with in el6, and people constantly touched the wrong one, had no idea how the end configs were actually compiled, etc., and I don't think anyone has ever gotten it wrong with the approach used now in el7. In the end, the srpm uses a merged config for each kernel build/arch, so it's simple for people doing their own custom builds to modify the right config, and the git tree heirarchy still makes it pretty obvious what's enabled where -- the path from single files to kernel-foo.config is pretty straight-forward and obvious. I don't think I have anything bad to say about this approach, other than "there are a lot of files", and the most difficult part was the initial conversion, making sure no end result config values differred from the prior method. -- Jarod Wilson [email protected] _______________________________________________ kernel mailing list -- [email protected] To unsubscribe send an email to [email protected]
