[OE-core] [PATCH 1/1] kern-tools: checkpoint restoration for reset branches

[Bruce Ashfield]

On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvhart at linux.intel.com> wrote:
>
>
> On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
>> Updating the SRCREV to pickup the following fix:
>>
>>     createme: fix checkpoint restoration for reset branches
>>
>>     The meta branch can optionally be merged out to BSP branches. This removes
>>     the need to restore the checkpoint when working with the tree.  The way
>>     it detects the merge is by checking to see how many branches contain the
>>     meta data. If there's more than one, the branch was was merged out.
>>
>>     Unless you are a BSP that isn't tracking the latest meta, and you get
>>     meta and meta-orig created. That's two branches and the code opts to not
>>     restore the checkpoint, which leads to configuration errors.
>>
>>     The fix is simple. We allow for 2 or less branches with meta, and will
>>     still restore the checkpoint. Three and up, we won't.
>>
>
> Uhm... am I the only one for whom this language is really confusing?
> "merged out" ?
> "restore the checkpoint" ?

I could be more verbose, but it's like reading a kernel -mm commit. I
don't grok everything they write, but they aren't writing it for me as a
-mm newbie.

> Why does a BSP using a different meta SRCREV get two meta branches?
>
> The fix of incrementing the allowed count of meta branches honestly
> feels like a bandaid. Why do we create two in the first place?

do_validate_branches() has to check if the HEAD of meta matches the meta
SRCREV that the BSP defines. If they don't match, it saves the old branch
as $branch-orig. So you have two branches, with the base meta commit
(which is what is tested).  I don't want to destroy any branches, since there
is value in keeping them around.

The tools are actually separate to the bitbake bindings, so they don't expect
this to happen. I could destroy the old branch in do_validate_branches, but
that's not a solution I particularly liked. It was easier to add some
flexibility to
the tools.

Cheers,

Bruce

>
> Regardless, this is a blocker for working with meta-intel, so we need
> this in. But it does seem to me that a more direct solution may be
> needed. Bruce, can you help fill me in re. the above?
>
> --
> Darren
>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield at windriver.com>
>> ---
>>  .../kern-tools/kern-tools-native_git.bb            |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> index b6fab39..b5e203e 100644
>> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8
>>
>>  DEPENDS = "git-native guilt-native"
>>
>> -SRCREV = "9bb704df0a86578b8ae1f4c85e45089bef28e026"
>> +SRCREV = "de3649840e8e3ca25bc79d2444f04a1b158a1769"
>>  PR = "r12"
>>  PV = "0.1+git${SRCPV}"
>>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



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