On 11/14/2012 06:11 PM, Ryan Harkin wrote:
On 14 November 2012 11:38, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Adding linaro-dev list and replying with some comments... On Tue, 2012-11-13 at 20:20 +0400, Andrey Konovalov wrote:
The llct tree itself has no suitable .conf or defconfig for vexpress at all. That's the problem (wrt the ci jobs).
The easier way seemed to be a single kernel/configs.git, config-boards-tracking branch to provide the config fragments for all the llct jobs. But it creates several instances of the same <board>.conf files and adds confusion. Agreed. Should we do in the jenkins jobs something like 'git checkout arm_lt/integration-linaro-vexpress.conf -- linaro/configs/vexpress.conf' for vexpress and similar (but different and unique) command for the other boards?
Yes, I see the problem. But getting CI jobs to pull configs direct from an LT tree seems like the wrong solution. I guess what people really need is configs in linux-linaro-core-tracking (llct) (I'm sure people have told me that before and I possibly didn't listen enough).
Now that the LT branches included in linux-linaro (ll) are based on llct, then they could modify the board configs in llct if required for the work in their topics. So at the moment, I can't think of a good reason not to pub all the board configs into llct. Can anyone else?
Having the boards config fragments in llct is fine for me. Advantageous even.
I don't know if we need the board configs to be sourced from a single repo, or allow board configs to be included in llct from LT trees. One central repo means that people know where to go
This seems like the easiest option to me. Let's do it this way unless someone gives a valid objection.
llct can only include topic branches. So I need to pull all the board configs into a single git branch anyway. See no big reason not to make this topic branch public (== the central repo known to people).
My question is if this topic branch would be kernel/configs.git, config-boards-tracking branch or something else?
(Unless we had an official maintainer to manage all commits to the tree.)
I assume this would have to be Andrey. Andrey, are you OK with that?
I am OK with that. Seems I just have no other choice :) Just don't expect a lot of intelligence from me in this role, and be prepared to dumb questions when something is not good with the board config fragments.
Or does someone else need to do it?
Each LT that is using LLCT would have to send a patch to get their config updated. So long as this happens in a timely manner, LTs should be able to live with that process.
Updating the board configs in the topic branch and the LLCT could be tied to the scheduled LLCT updates - every Tuesday that is. And on request if there is something urgent.
As for me, the board configs are good, as long as the resulting kernels build, boot ok in LAVA, and pass basic LAVA tests.
Or course, once Linaro's build and test infrastructure supports config fragments fully, then we could have have separate config fragments for
- basic board config
- new board enablement
Not sure if I follow this 100%... Can I have an example of "new board enablement" vs "basic board config" config fragment?
- special features (e.g. big.LITTLE MP)
- testing or benchmarking config
and the configs could live in the tree relevant to the code they apply to rather than having a single central board config we have to manage.
There is already big-LITTLE-MP.conf in the LLCT tree which comes from the big-LITTLE-MP topic.
That sounds scarey - there would be no one place to get a config, but I guess, if you need a config for feature X, you'd also need the branch for feature X that contained the source and config, so it would work out fine.
Yes. This is the case for big.LITTLE MP, and hopefully the other upcoming topics would follow this as an example. In the "testing config" case, I wouldn't be surprised by a topic being just the config fragment (provided that all the relevant code is already in the tree). Then for building and testing the stuff in e.g. the LLCT, one would need just to specify the list of the (in the tree) config fragments to use. (But the build infrastructure should allow using the config fragments from other repositories/branches too.) The board config fragments would go into the LLCT via the board configs topic.
Thanks, Andrey