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.
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.