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

Bruce Ashfield bruce.ashfield at gmail.com
Sun Dec 26 21:24:48 PST 2010


On Thu, Dec 23, 2010 at 12:14 PM, Bruce Ashfield
<bruce.ashfield at gmail.com> wrote:
> 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 ?

So doing a bit more thinking about this .. is this as simple as having
any self contained  BSP use a SRCREV= (with no override), or have them
use an override with less precedence than machine (i.e. SRCREV_<distro/arch/os>
(or something new) ?

We'd then have the main revisions file set a higher precedence value,
which allows changes to be pushed out, and for the BSPs to have their
own settings are required.

But does that leave the ability for a BSP to disregard the distro/main
settings if required ? If I read things properly, it should still be possible
with a local override.

Comments ?

Bruce

>
> Cheers,
>
> Bruce
>
> I guess that's
>
>>
>> Cheers,
>>
>> Richard
>>
>>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
>



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



More information about the poky mailing list