Config fragment for Versatile Express
john.stultz at linaro.org
Mon Apr 2 19:30:41 UTC 2012
On 04/02/2012 06:58 AM, Andy Green wrote:
> On 04/02/2012 09:40 PM, Somebody in the thread at some point said:
>> On Mon, 2012-04-02 at 21:10 +0800, Andy Green wrote:
>>> If you want to do it with this complex directory scheme, please don't so
>>> anything to the definitive sources that makes it mandatory.
>> Just so I understand properly, are you saying that for the TI kernels
>> you want to just supply a single fully featured defconfig file and have
>> that used to produce builds, rather than having one built up from OMAP
>> bits supplied by you and other android/ubuntu/linaro bits obtained from
>> another source?
> Not at all.
> I don't want to sound like a broken record but we have been doing this
> layered config stuff for a long time. It's a very good wheeze and
> centralizing some of it will give good results if we can do it in a good
> Here's an example from our repo.
> Currently our vanilla tree ends at
> that's made up of many topics each of which add to the single defconfig
> omap_5430evm_defconfig so it builds and configures for the topic
> content. At this end point, it has all the topic patches in and all the
> topic config enabled.
> An example of what we have been talking about can be found at the
> "flavour" branch lat-3.3.
> This is based on the vanilla tree from tracking-topic-omapdrm, it
> contains the generic androidization patches.
> At the end of lat-3.3, I have a patch "config OMAP5 Android" which
> adapts the single defconfig that came in from vanilla,
> omap_5430evm_defconfig, to have generic Androidization options
> So when you check out lat-3.3 or one of the tags pointing at it, you get
> always up-to-date, androidized, omap4+omap5 defconfig with the same name
> as vanilla.
> The defconfig you check out at the vanilla tree back at
> tracking-topic-omapdrm doesn't have to know or take care or be affected
> by any of that.
So, to make sure I'm following properly here, would it be fair to call
this somewhat of an "additive", or "constructive" style config
management, where you have your board defconfig, which you add to the
end of your base tree, then any branches based off of that base tree
will also contain patches to the board defconfig that enable the new
features found in that branch?
In this way you have one config, that each branch adds to as needed.
> When it's available and we're able to, we'll also start putting out a
> new flavour branch which has linux-linaro-tracking "flavoured" on to it,
> and just like in lat-3.3 case we will modify the vanilla defconfig
> according to what that flavour needs.
> All we require is that the flavour tree, be it
> linux-androidization-tracking, or linux-linaro-tracking, comes with a
> patch containing the defconfig delta that's meaningful for it.
> If that makes sense, you can see there's no need for directory
> structures, the various flavour and result trees can contain all the
> deltas and variant defconfigs.
So part of the config fragment work is motivated by the need to have
consistent configs across a number of boards.
While the method you described above works well for managing
board-specific config features enabled by LT branches, the config
fragment work is trying to find a way to help simplify config management
for features that are generic.
An example is the SCHED_MC item that I know Amit had to chase a few
times in order to make sure it was enabled in all the various build
configs, and that it stayed enabled as folks rebased forward to new
Initially I was hoping to provide a basic set of configs split up by
base/distro/board. Then have folks use the same additive method you
describe above to enable features per branch (in the appropriate config
so LT's branches modifying the board config fragment, while
power-management team's branches can modify the base fragment).
The difficulty is that as Tixy earlier pointed out, are that the LT
kernel trees are mainline based, and thus aren't based off of something
that would contain the base/distro/board config fragments.
One approach we might be able to use is if the board defconfigs really
are minimal, and restricted in scope to only the board options, we could
switch the merge order (board/distro/base). This way the LT's "additive"
defconfig can be used (from arch/arm/configs/ ) and we can still also
get consistent generic options as well.
The only issue with this idea is that it goes specific->generic it
doesn't allow us to add board-specific hacks like Tixy's IPv6 example,
since the last fragment wins.
Any other ideas?
More information about the linaro-dev