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

[Robert Yang <liezhi.yang@windriver.com>]

Hi RP,

Thanks, clear enough, here are the summary. For anyone who
cares about runqemu, please free to give your comments, I will
start working on it sooner.
1) Use python to replace of shell
2) Preserve the current command line options
3) Remove any machine knowledges out of runqemu scripts
4) I'm not sure whether we should remove arch knowledges out of runqemu,
    I'd like to keep them, this can make bsp add runqemu support easier.
5) Add qemu-boot.bbclass to help create boot files during build.
6) Use python3.

// Robert

On 06/23/2016 04:56 PM, Richard Purdie wrote:
> 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
>