Re: [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2016-06-23 at 16:43 +0800, Robert Yang wrote:
> On 06/23/2016 04:17 PM, Richard Purdie wrote:
> > On Tue, 2016-05-10 at 01:13 -0700, Robert Yang wrote:
> > Sorry about not responding to this before now. My concerns:
> > 
> > a) The commandline structure is changing and I'm not sure I like
> > the
> > new one or believe its an improvement. This is particularly
> > problematic
> > from a documentation perspective. Is there a way to preserve the
> > existing syntax?
> 
> I did like to preserve the existing command, but the main problem is
> that then we had to hardcode the MACHINE knowledge into the code,
> for example, when we run:
> runqemu qemux86-64 core-image-sato
> 
> The qemux86-64 should be hardcoded into the code, otherwise it
> doesn't know this is a machine arg or typo.

If we use python code, we can ask bitbake if "qemux86-64" is a valid
MACHINE or not?

We could assume that images are in DEPLOY_DIR/MACHINE and at least try
looking to see if such a qemu-boot file exists? We could then error and
simply inform them that there didn't appear to be any data for "qemu86
-64" available. DEPLOY_DIR could come from bitbake -e. 

We could add in functionality to make it take an argument of a path to
the qemu-boot directory so that if the first option looks like a
relative/absolute PATH, try to see if a qemu-boot file exists there. If
it doesn't, it can then fall back to slower ops?

> > c) I don't think qemu-boot should be added be hardcoded into
> > image.bbclass, we need to find a better way to do this.
> 
> Sorry, I don't quite understand this, the code inside image.bbclass
> is:
> 
> +QEMU_BOOT_CLASS = "${@base_conditional('QEMU_BOOT_SUPPORTED', '1',
> 'qemu-boot', 
> '', d)}"
> +inherit ${QEMU_BOOT_CLASS}
> 
> It doesn't look like a hardcode ?

Imagine that qemu.inc does:

IMAGE_CLASSES += "qemu-boot"

You then shouldn't need to change image.bbclass at all, its much
cleaner. I don't like much of the way image.bbclass deals with all its
subclasses at the moment and don't want to make it worse.

Cheers,

Richard