From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5Kmj-0006R0-4Y for qemu-devel@nongnu.org; Wed, 07 Mar 2012 12:36:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S5Kmb-0006kd-Ty for qemu-devel@nongnu.org; Wed, 07 Mar 2012 12:36:20 -0500 Received: from mail-pz0-f52.google.com ([209.85.210.52]:53149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5Kmb-0006kO-NJ for qemu-devel@nongnu.org; Wed, 07 Mar 2012 12:36:13 -0500 Received: by dadp12 with SMTP id p12so8171326dad.11 for ; Wed, 07 Mar 2012 09:36:10 -0800 (PST) Message-ID: <4F579C86.9000703@codemonkey.ws> Date: Wed, 07 Mar 2012 11:36:06 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20120307133644.63d2e662@doriath.home> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Paolo Bonzini Cc: qemu-devel@nongnu.org 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? With QAPI async command, I don't think 1.1 is a viable target. We're not just talking about converting existing commands to QAPI, but also replacing the QMP server infrastructure. I don't think that is a change that should be made at the tail end of the development cycle. Regards, Anthony Liguori > > Paolo > > >