qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QAPI conversion status and async commands support


From: Alon Levy
Subject: Re: [Qemu-devel] QAPI conversion status and async commands support
Date: Wed, 7 Mar 2012 22:06:31 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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
> >
> >
> >
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]