[PATCH 00/12][RFC] Intial Kconfig Fragment Demo
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:
> 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
> 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
> 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
> 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
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.
> 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
> 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
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
More information about the linaro-dev