From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47359) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5N8Q-0007aq-JJ for qemu-devel@nongnu.org; Wed, 07 Mar 2012 15:07:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S5N8H-0004GK-3k for qemu-devel@nongnu.org; Wed, 07 Mar 2012 15:06:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5N8G-0004G2-R2 for qemu-devel@nongnu.org; Wed, 07 Mar 2012 15:06:45 -0500 Date: Wed, 7 Mar 2012 22:06:31 +0200 From: Alon Levy Message-ID: <20120307200631.GC9524@garlic.redhat.com> References: <20120307133644.63d2e662@doriath.home> <4F579C86.9000703@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F579C86.9000703@codemonkey.ws> 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 , Avidan Kivity Cc: Paolo Bonzini , qemu-devel@nongnu.org On Wed, Mar 07, 2012 at 11:36:06AM -0600, Anthony Liguori wrote: > 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. ... so, Avi, Anthony, as: 1. screendump is broken for qxl 2. there will not be QAPI async for 1.1 3. monitor async is unacceptable by maintainer Is screendump-async to be accepted? > > Regards, > > Anthony Liguori > > > > >Paolo > > > > > > > >