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