On 04/02/2012 07:40 PM, Somebody in the thread at some point said:
On Mon, 2012-04-02 at 11:31 +0100, Jon Medhurst (Tixy) wrote:
On Mon, 2012-04-02 at 17:45 +0800, Andy Green wrote:
On 04/02/2012 05:31 PM, Somebody in the thread at some point said:
[snipped my suggestion about organising lots of config fragment]
I don't think this is a good way. There are two things we found having already being doing "config fragments" for about a year in TI LT repo.
having multiple defconfigs is a mistake, they will diverge
the fragments themselves rot quickly from changes in mainline, both
by way of defaults changing and diffing the defconfig not being a perfect fit for what it represents (the defconfig is an output of another process out of sight with its own inputs, so the patches in the tree changing it are not the only things touching it). In particular it's almost impossible to hold the line with multiple finegrained config changes in one topic, we now squash everything into one config patch per topic.
I can see that lot's of fragments might be a problem, but I think we need some middle ground.
I accidentally sent my previous reply whilst still editing it, and then couldn't think of what I wanted to say.
One problem I'm worried about is bloat and rot caused by a config that just constantly expanded and patched. Currently, our Ubuntu kernels use a config got from the pre-existing vexpress builds which seemed to include a lot of OMAP devices and various miscellaneous crap.
Another issue is we occasionally get requirements or bugs which require config option to be applied across all kernels.
I guess I think the current split with board/base/{linaro|android} is about right. At least if the common bits have a permanent home in a git repo, then we have a single place to apply system wide changes and the git log can explain the history of configs change.
Something to bear in mind is what happens to the "single defconfig" is spread over multiple output trees / branches each with a different purpose and context.
So patching CONFIG_ANDROID etc on to the common defconfig is not that scary and prone to rot when you consider it happens only on the branch you flavoured with linaro-androidization-tracking, by one patch on that flavouring branch used by all the LTs the same. Ie, you end up only seeing CONFIG_ANDROID on top of your minimal config *in the android branch*, which is what you want.
Your source tree that was used as an ingredient in the flavouring is "read-only" for that purpose and his defconfig stays the same -- that's the came for other "flavourings" like linux-linaro as well.
So as long as your minimal defconfig in your LT tree is in good shape for your board, you can transform it many different ways in the flavouring trees without adding risk and keeping the advantage that the flavoured versions inherit your definitive minimal config set relevant to the board.
One issue I think we will have is if there are any board specific platform level hacks or workarounds. E.g. how do do an Android specific config change for vexpress when android.conf doesn't live in our tree? I guess that if the board conf settings always override the generic one, then we can just have and android topic which patches our board conf.
Yes that was how we did our Android tree before, like this
- vanilla tree - Panda-specific Android features (SGX) + android defconfig - androidization patches
Now we will do it slightly differently, not just to conform to a common config fragment but because we learned it's a better flow
- vanilla tree - generic androidization + androidize our vanilla defconfig - Panda-specific Android features (SGX) + additional defconfig bits
In TI LT we script and manage these flows across multiple trees so very little is by hand and not reproducible; you don't have to use our same scheme but you'll need something to automate it, especially when more flavours appear. We also use rebases so we know what is where (and our trees are fully serialized) when other people think merges are better when combining flavours.
-Andy