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 way.
Here's an example from our repo.
Currently our vanilla tree ends at
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...
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.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...
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
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=commi...
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 kernel versions.
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?
thanks -john