From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5cUy-0007VJ-1C for qemu-devel@nongnu.org; Thu, 08 Mar 2012 07:31:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S5cUn-0002zo-Pc for qemu-devel@nongnu.org; Thu, 08 Mar 2012 07:31:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5cUn-0002zS-H1 for qemu-devel@nongnu.org; Thu, 08 Mar 2012 07:31:01 -0500 Message-ID: <4F58A755.9050000@redhat.com> Date: Thu, 08 Mar 2012 13:34:29 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <20120307133644.63d2e662@doriath.home> <4F579C86.9000703@codemonkey.ws> In-Reply-To: <4F579C86.9000703@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QAPI conversion status and async commands support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , qemu-devel@nongnu.org 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