[poky] [PATCH 1/4] meta-emenlow: update to the new BSP layout

[Bruce Ashfield]

On Thu, Dec 23, 2010 at 12:00 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Wed, 2010-12-22 at 06:06 -0800, Bruce Ashfield wrote:
>> I was just thinking about this while reading your patch series, and I'm
>> caught between two problems here.
>>
>> I like:
>>
>>   - BSPs that are self contained.
>>
>> I'm ambivalent:
>>
>>   - about having to update a lot of SRCREVs when I update the BSP branches.
>>
>> I have a problem:
>>
>>   - If all the SRCREVs are not in a single location, I can't hunt them all down
>>     and update them effectively. That makes point #2 into "strongly" dislike.
>>
>> I've got 350+ patches that are about to land for 2.6.34 (from the
>> 2.6.34 -longterm
>> tree), and I'll be merging them out to the BSPs. So this SRCREV along with the
>> rest will change.
>>
>> I'm looking for something that is effective in controlling the
>> branches, but is also
>> maintainable.
>>
>> Richard: can we have a central SRCREV in the default revisions (per
>> machine still), and
>> then override it in a BSP layer ? That way if for some reason you
>> don't have the
>> default revisions your BSP will be standalone, but I still have a way
>> to update everything
>> at once (and we'll eventually update the BSP layers as well).
>>
>> I can also set the SRCREVs in the recipes themselves via python (i.e.
>> set a default
>> again), that allows me a single point of control .. but perhaps
>> doesn't match existing
>> solutions.
>
> We have all the options with the syntax we have. You can set things in
> the core, the BSP can override, we can set things in the BSP that
> override the core.
>
> If you can clearly describe a consistent way you need the variables to
> work, we can then implement it :)

I can do just that :). I'll finish up what I'm working on and send out something
more detailed, but here's a high level RFC on a way that we can have self
contained BSPs and way that I can get updates pushed into them at the
same time.

I'd consider it levels of trust. The BSP (if it is maintained) can have a SRCREV
indicating that the BSP maintainer has tested with a particular set
of changes. At the same time, I need to be able to get them important fixes
and features, which can be set in a central location. These may not have bee
explicitly tested on a BSP, and when that testing is done, the BSP SRCREV
updates.

For me, this would take the form of setting something in the local.conf that
indicates whether you prefer the BSP vs system maintainer view of the
BSP content. I can easily switch on that, and use it to set the SRCREV
for the fetcher. To me this smells like what we already have with

 SRCREV_<machine> vs SRCREV

But we do need those per-machine SRCREVs available to do per-branch
content control. So we can't go to the system wide setting only manipulating
SRCREV vs a BSP setting the override. Is there some other functionality
that we can use to achieve what I describe without me adding to the
python in the kernel recipes ?

Cheers,

Bruce

I guess that's

>
> Cheers,
>
> Richard
>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"