[meta-virtualization] [RFC 0/8] Update to Xen 4.5.0 and add AArch64 support

[Nathan Rossi]

> -----Original Message-----
> From: Chris Patterson [mailto:cjp256 at gmail.com]
> Sent: Monday, February 09, 2015 1:24 PM
> To: Nathan Rossi
> Cc: meta-virtualization at yoctoproject.org
> Subject: Re: [meta-virtualization] [RFC 0/8] Update to Xen 4.5.0 and add
> AArch64 support
> 
> 
> 	>
> 	>
> 	> Thanks for that, that looks good! For the cherry-pick of the "xen:
> break
> 	> out firmware bits" could you just add Signed-off by for Eric
> Chanudet
> 	> <eric.chanudet at gmail.com> for the portions I borrowed from his
> other work
> 	> on openxt?  I meant to do that before I pushed.  I fixed and
> rebased @
> 	> https://github.com/cjp256/meta-virtualization/tree/add-aarch64-
> support
> 	>
> 	> Otherwise, there is just some minor recipe cleanup and an issue
> with
> 	> hvmloader picking up ipxe I wanted to look into which could be
> done with
> 	> follow up patches.
> 
> 
> 	I have updated my branch from yours, I have also rebased it on top
> of current master.
> 
> 
> 
> 
> I pushed a couple minor cleanup patches to my branch, feel free to absorb
> them or I can submit them independently later.

I will absorb them into my patch series :).

> 
> 
> 
> 	>
> 	>
> 	> Out of curiosity, I noticed in your qemu bbappend that you use
> 	> PACKAGECONFIG[_defaultval].  I've never seen that before, is that
> 	> supported?  I have seen PACKAGECONFIG += which I believe
> accomplishes your
> 	> goal.  Your method apparently works though :)
> 	>
> 
> 	The _defaultval flag is an bitbake internal one, it is how bitbake
> stores the ??= value until its finished parsing. So += onto it works as
> desired. Looking into it I cannot find any use or mention on whether or
> not internal flags are acceptable for use in user recipes. I liked this
> method the best as it allowed for future control of what is done within to
> be in the meta-virtualization layer, the alternatives to get the same
> functionality is to either submit the change to oe-core or to use ??= and
> override the default (which means the override might get out of sync and
> cause people issues). I had initially planned on submitting the qemu
> changes to oe-core (until I found the _defaultval trick), do you think
> that would be a better approach?
> 
> 
> 
> 
> It may be a better approach (if they'll take it), but it does not matter
> to me.  It's a little surprising there isn't a built-in mechanic to
> support this case, but props for figuring out how to get around that.

We will see, I have just sent the patch.
http://lists.openembedded.org/pipermail/openembedded-core/2015-February/101576.html

Regards,
Nathan

> 
> 
> 
> 	Also PACKAGECONFIG += "xen" unfortunately ignores the value set by
> ??= and becomes just "xen", _append would work fine however it will always
> apply the append (even when overriding with _pn-qemu = "" from
> local.conf). Which is why the patch uses += to the defaultval.
> 
> 
> 
> 
> Thanks for the info, good to know.
> 
> 
> 
> 	Regards,
> 	Nathan
> 
>