[Top][All Lists]

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

Re: [Qemu-devel] Dropping the MONITOR_CMD_ASYNC

From: Anthony Liguori
Subject: Re: [Qemu-devel] Dropping the MONITOR_CMD_ASYNC
Date: Mon, 12 Dec 2011 10:23:22 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 12/11/2011 04:29 AM, Alon Levy wrote:
On Thu, Dec 08, 2011 at 05:45:44PM -0200, Luiz Capitulino wrote:
Hi there,

I'm about to completely drop the MONITOR_CMD_ASYNC API, but it turns out that
the command client_migrate_info uses it. That's a legacy interface and has to
be dropped, no command should be using it...

Something tells me that if I just drop it (and change the command to use the
regular interface), bad things will happen. Am I right? :)

The monitor command client_migrate_info needs to complete after getting

Then it's completely broken. CMD_ASYNC is broken and should have been removed a long time ago.

Unfortunately, we're going to have to remove this command until we can move to full QAPI. I see this went in through Gerd's tree:

commit edc5cb1a52b2847201acf78b0fba67ab3c2464d5
Author: Yonit Halperin <address@hidden>
Date:   Mon Oct 17 10:03:18 2011 +0200

    spice: turn client_migrate_info to async

Changes to monitor commands really should at least carry an Acked-by from the QMP maintainer (Luiz). That would have prevented this from happening.

I'll try to be more diligent about enforcing this in the future.


Anthony Liguori

an ACK message from the currently connected spice client (this is the
only case where this is required - if there is no client then the
MONITOR_CMD_ASYNC API won't be used). This in turn requires the main
thread to perform select and call the callback that will process this
ACK. That's why the MONITOR_CMD_ASYNC API was used.

I'm not aware of any other way to do this, I'll be glad for any help
here. Also, I understand this is not what is not true async, since one
would expect a true async interface to support multiple in flight
monitor commands. If there is any ETA or existing way to do this we
could change the implementation of client_migrate_info.


reply via email to

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