Config fragment for Versatile Express
andy.green at linaro.org
Wed Apr 4 12:31:12 UTC 2012
On 04/04/2012 06:20 PM, Somebody in the thread at some point said:
> On 04/04/2012 01:02 PM, Jon Medhurst (Tixy) wrote:
>> On Wed, 2012-04-04 at 10:05 +0530, Tushar Behera wrote:
>>> On 04/03/2012 03:59 PM, Jon Medhurst (Tixy) wrote:
>>>> I think it makes sense if this 'upstream' doesn't include board files
>>>> though, they should come from LT trees.
>>> As for the board specific fragments, I feel it would be better if the
>>> config-upstream tree has the initial fragment (which I suppose is
>>> minimal enough to compile the common kernel). That way anyone taking
>>> linux-linaro-tracking can have at least a working setup.
>> I thought linux-linaro-tracking was going to operate a bit like
>> linux-next, i.e. just a merge of all the topics from LTs and working
>> groups, and from which Linaro produces it's releases and does some CI
>> build+test. If that's true, then anyone using that tree will always have
>> the LT code.
> In some cases, the mainline kernel cannot boot a specific board using
> the default config file. If we have a config fragment that adds the
> necessary changes, people can use that specific board even if LT has no
> other enablement patches merged to linux-linaro-tracking.
> An example would be the thermal patches, which got merged to
> linux-linaro-tracking through PM WG. But for someone to validate those
> changes, they won't have a definite config to build
> linux-linaro-tracking and run on Origen board. Hence I feel that having
> a minimal board fragment, that boots the kernel till console, in
> linux-linaro-samsung would be helpful.
> As long as we have same set of commits in our tree, we won't have merge
> conflicts too.
>> Though I guess if LT code breaks other boards and has to get temporarily
>> dropped, and if that LT code was pulled in as one monolithic topic like
>> TI and Samsung trees, then it would probably mean dropping the board
>> config too if we had that coming from the LT tree. But in that case,
>> does it matter that the broken board can't be built from
> That is one concern from my side too, as to how do we build
> linux-linaro-tracking kernel and what all things goes into that.
That's a slightly different issue. If stuff that's too avant garde is
put into linux-linaro-tracking it'll break one or more lt trees in a way
that can't be quickly fixed.
This was seen in January where I tried to base on it, it broke my tree,
called for help, got ignored for weeks until it was too late to care
about that release because tracking had moved on.
In the end LTs can only help solve issues that fall into their areas of
competence, which is far from infinite. If enough next-y stuff is
shovelled into linux-linaro-tracking and we're left to it, it'll break
all the LT trees. But I think that's understood and there's some
attempt to keep it sane and hopefully now take care of any damage it causes.
The big problem in front of us today is "how well do the LTs trees fit
together right now as a starting point?". We don't seem to be trying to
bind the available trees at v3.3 together at the moment so we can
understand our situation for some reason. Instead we're trying to use a
single LT tree as an exemplar for a process that is all about binding
all the trees.
Maybe we should take some time to do a full scope trial run and start
making the small improvements that will be needed for them to slot
together well ongoing.
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
More information about the linaro-dev