[RFC] First pass config fragment breakout for linaro kernel
tushar.behera at linaro.org
Thu Mar 29 04:37:27 UTC 2012
On 03/28/2012 10:17 PM, John Stultz wrote:
> On 03/28/2012 05:24 AM, Tushar Behera wrote:
>> On 03/27/2012 12:50 AM, John Stultz wrote:
>>> So after talking about it at the last Linaro Connect, I've finally
>>> gotten around to making a first pass at providing config fragments for
>>> the linaro kernel. I'd like to propose merging this for 12.04, and
>>> doing so early so we can make sure that all the desired config options
>>> are present in the fragments and to allow the vairous linaro build
>>> systems to begin migrating their config generation over.
>>> The current tree is here:
>>> The most relevant commit being:
>>> This includes config fragments for a linaro-base, an android-ization
>>> fragment, and board configs for panda, origen and imx53.
>>> I suspect we'll need an ubuntu specific fragment as well as all the
>>> other board fragments.
>>> There is likely to be quite a bit of churn as we decide what sort of
>>> configs are really common and which are board specific. But that's ok.
>>> Configs are generated from the config fragments, as follows:
>>> ./scripts/kconfig/merge_config.sh ./configs/linaro-base.conf
>>> ./configs/android.conf ./configs/panda.conf
>>> You may see warnings, which are not fatal, but should be reported so
>>> they can be properly cleaned up.
>>> I'm asking for Build folks to take a look at the above and consider how
>>> they might merge in fragment assembly into their system replacing their
>>> current config generation.
>>> I'd ask Landing teams to take a look at this, and report any missing
>>> config options or fragment chunks they'd like to see.
>> I have updated origen.conf and linaro-base.conf for testing Samsung LT
>> kernel. The results are updated in .
> I'll take a look at the changes and try to merge them into my tree.
>> I have not validated the changes in android.conf, but by merging
>> linaro-base.conf and origen.conf, I was able to boot my kernel the way I
>> would have expected when using exynos4_defconfig.
>> One thing I notice is that I find far too many debug messages with this
>> new config.
> You mean the debug output from the merge_config.sh script is a bit
> noisy? Yea. Likely we'll have some extra noise as we settle out what
> options needs to be generic vs board specific. But it should decrease
> over time.
I was talking about the console log messages upon booting on a target board.
>> Going forward, would it be better to have linaro-base.conf, android.conf
>> and ubuntu.conf managed centrally and each LT managing their board
>> specific configuration file. That way, we can include the changes in our
>> board specific configurations in respective topic branches.
> So yea, I'd like to delegate/give away as much management of the configs
> as possible. :)
> That said, I do think that we'll need someone looking at the entire
> cross-board fragment picture (since if everyone needs an option, it
> really isn't board specific). So it might be a good idea to have basic
> board config fragments that work with upstream. Then any board-specific
> feature branches can add their config needs in as a patch on top.
> Does that sound reasonable?
Sounds good. Any config that enables a feature on a topic branch
specific to a board should go in a patch in the topic branch itself.
More information about the linaro-dev