cc'ing Ubuntu kernel team. We use their config system today and this might be of interest to them for the future.
On Wed, Mar 9, 2011 at 4:32 AM, John Stultz <john.stu...@linaro.org> wrote: > This patch set provides enough to demo how the Kconfig fragment > based defconfigs could be used to simplify both generating and > managing the configs used to build Linaro kernels. > > This is for the kernel config managment tool and dependent bluprints: > https://blueprints.launchpad.net/linux-linaro/+spec/other-kernel-config-management-tool > > > The basic idea is to use a Kconfig fragment to generate the > per-board defconfigs. The Kconfig fragments contain a meta-option > that defaults to yes, which then selects the needed config values > to enable a system. > > This has been proposed by others, and we're using Stephen > Rothwell's initial patch to start things off. > > Once we have the infrasturcture to use Kconfig fragments for > defconfigs we had to overcome some limitations: > 1) We cannot select items from a choice block > 2) We need a way to select for values and modules. > > Limitation #1 is resolved by a patch to the kbuild system I > made. > > Limitation #2 is unsolved, but Jason Hui found a workaround that > is sufficient. Basically we can just redefine the default with a > short declaration: > config VAL > default 256 > or > config VAL > default m > > > With these two solutions, I went forward generating basic Kconfig > fragments for omap3, imx51 and vexpress. > > Getting per-board defconfigs is only of limited value, because > we also want to be able to have a common policy settings for > Linaro kernels. Many distros run into this problem, and use > .config fragments which are then assembled at package build > time. > > My solution is to have a Kconfig.distro file, which is patched > with Distro specific policy config, such as which filesystems > should be enabled, networking policy, debug options, or periphrial > driver modules that should be enabled. Basically anything that > isn't hardware specific (by that I mean, part of the architecture > or wired on the board). The Ubuntu configs do something similar. The config generator makes a 3-level config - distro, arch, board. But this is encapsulated under the debian packaging rather than in the kernel source. That is why you probably haven't seen it yet. Look at git://git.linaro.org/ubuntu/linux-linaro-natty.git under debian.linaro/config. Most kernel developers, however, don't really care about creating a .deb package of the kernel to test new code. They'd rather have the config available in the sources. So I agree that we should fix this problem for them. If it turns out that in fixing this problem we fix it for distros too, great! > From there, I add in as much of the generic Linaro config policy > as I could, utilizing the config files that were used to build > the omap3, imx51 and vexpress hardware packs. > > Since the Linaro config polciy is not unified at this point > (in other words, each board has totally different set of generic > policy options configured). I added the per target differences > into the board kconfig fragments. No, it doesn't. The system they use allows for unified configs. The Ubuntu kernel has unified configs across 3-4 architectures. The problem is starting a new config for a new board/SoC. The current config system expects a full config for the board dropped into place and then let the tool split it out into distro/arch and board components. If this causes any changes to the distro/arch configs, you know you might have missed some options. > Ideally we can review and settle down on specific linaro config > policy and this generic per-board stuff can go away. > > These are initial and rough patches, but are the result of lots > of painful manual labor to match the Linaro .configs as closely > as possible. > > There are a few remaining issues, but these can probably be > worked around: > 1) Omap has a strange tristate choice option for the usb gadget > options. So you can only pick one, or you can pick multiple items > as modules. My choice selection patch doesn't yet address this. > I need to see how common this style of choice is and see if we > can either just make it a non-choice options block or if other > fixes are needed. > > 2) Not having a module selction is a little painful, as the > module "default m" entries are numerous and annoyingly separate > from the meta-config selects. > > 3) The Kconfig.distro file should be probably broken up into > policy topics, like networking, filesystems, peripherials, etc. > > 4) The current board Kconfig fragments are named slightly > differently from the standard defconfigs to allow testing > with both. That will need to be fixed, and the old defconfigs > removed prior to submitting. > > 5) The igep, overo, and panda configs all use the same omap3 > config according to the hwpacks. I'm not sure I believe that, > but went along with it to get this out the door. They do use the same config - or 'flavour' as they are referred to in the Ubuntu kernel config system. > Many thanks to Jason for his help figuring out an approach here. > > Feedback and thoughts would be greatly appreciated. > > thanks > -john > > > CC: Grant Likely <grant.lik...@secretlab.ca> > CC: Jason Hui <jason....@linaro.org> > CC: patc...@linaro.org > > > John Stultz (11): > kbuild: Allow configs from choice blocks to be selected. > kbuild: Use kconfig defaults as defconfig starting point > kbuild: Avoid kconfig fragment defconfigs from having odd config > order > Add blank Kconfig.distro fragment file > Initial omap3 Kconfig fragment > Initial imx51 defconfig fragment > Add initial vexpress defconfig fragment > Add Linaro config policy to Kconfig.distro > omap3 kconfig fragment changes to align with linaro build > Update imx51 to better match linaro configs > Update vexpress to be closer to linaro config > > Stephen Rothwell (1): > kbuild: Enable building defconfigs from Kconfig files > > Kconfig.distro | 1754 +++++++++++++++++++++++++++++ > arch/arm/configs/Kconfig.imx51 | 503 +++++++++ > arch/arm/configs/Kconfig.omap3 | 2430 > ++++++++++++++++++++++++++++++++++++++++ > arch/arm/configs/Kconfig.vexp | 234 ++++ > scripts/kconfig/Makefile | 16 +- > scripts/kconfig/symbol.c | 15 +- > 6 files changed, 4949 insertions(+), 3 deletions(-) > create mode 100644 Kconfig.distro > create mode 100644 arch/arm/configs/Kconfig.imx51 > create mode 100644 arch/arm/configs/Kconfig.omap3 > create mode 100644 arch/arm/configs/Kconfig.vexp > > -- > 1.7.3.2.146.gca209 > > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
