[PATCH 00/12][RFC] Intial Kconfig Fragment Demo

Amit Kucheria amit.kucheria at linaro.org
Wed Mar 9 08:17:50 UTC 2011


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.stultz at 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.likely at secretlab.ca>
> CC: Jason Hui <jason.hui at linaro.org>
> CC: patches at 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 at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>



More information about the linaro-dev mailing list