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

Chris Patterson cjp256 at gmail.com
Sun Feb 8 19:23:50 PST 2015

> >
> >
> > 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.

> >
> > 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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-virtualization/attachments/20150208/ad526ad8/attachment.html>

More information about the meta-virtualization mailing list