[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QAPI conversion status and async commands support
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] QAPI conversion status and async commands support |
Date: |
Thu, 08 Mar 2012 13:34:29 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 |
Am 07.03.2012 18:36, schrieb Anthony Liguori:
> On 03/07/2012 11:29 AM, Paolo Bonzini wrote:
>> Il 07/03/2012 17:36, Luiz Capitulino ha scritto:
>>> Hi there,
>>>
>>> In the last few weeks we've had some proposals for new QMP commands that
>>> need
>>> to be asynchronous. As we lack a standard asynchronous API today, each
>>> command
>>> ends up adding its own way to execute in the background.
>>>
>>> This multiplies the API complexity as each command has to be implemented and
>>> learned by clients separately, with their own way of doing more or less the
>>> same things.
>>>
>>> The solution for this, envisioned for us for a long time now, is to
>>> introduce
>>> an unified QMP API for asynchronous commands.
>>>
>>> But before doing this we have to:
>>>
>>> 1. Finish the commands conversion to the QAPI
>>>
>>> This is almost done, the only missing commands are:
>>> add_graphics_client,
>>> do_closefd, do_device_add, do_device_del, do_getfd, do_migrate,
>>> do_netdev_add, do_netdev_del, do_qmp_capabilities and do_screen_dump.
>>>
>>> Note that do_migrate has already been posted to the list, and I have
>>> the screendump more or less done. Also, Anthony has an old branch
>>> where most
>>> of the conversions are already done, they just need to be rebased&
>>> tested.
>>>
>>> 2. Integrate the new QAPI server
>>>
>>> Implemented by Anthony, may have missing pieces.
>>>
>>> 3. Implement async command support
>>>
>>>
>>> I think the missing commands to be converted can be done in around one week,
>>> but unfortunately I've been busy at other things and will need a few days to
>>> resume this work. Then there's the new QAPI server& async support, which
>>> I'm
>>> not sure how much time we'll need to integrate them, but we should have this
>>> done for 1.1.
>>>
>>> The main question is: what should we do for the already posted async
>>> commands?
>>> Should we hold them until we finish this work?
>>
>> I think yes, and we could even have a list of features without which 1.1
>> should not ship. QOM buses, drive mirroring and QAPI async command
>> support may be them. Perhaps qtest too.
>
> Okay, let's get serious about what we can and can't do.
>
> Hard freeze for 1.1 is May 1st which is roughly 6 weeks from now.
>
> I think QOM buses can go in no problem along with qtest. I would be okay
> considering QOM buses a release blocker but probably not qtest.
>
> I'm not really sure about drive mirroring. Is the work already done such
> that
> we just need to talk about merging it?
There are patches, but they still need review. I think it's doable for
1.1. But in any case I don't think there's any justification for it to
be a release blocker. If anything in the block layer should be one, I'd
consider basic qcow3 support closest.
Kevin