On Wed, Mar 07, 2012 at 10:06:31PM +0200, Alon Levy wrote: > 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?
I've send a patchset that works for hmp and I intend to fix libvirt by using the hmp screendump command instead of the qmp one for now. See: http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg01802.html > > > > > Regards, > > > > Anthony Liguori > > > > > > > >Paolo > > > > > > > > > > > > > >