From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaSXW-0004uq-Pp for qemu-devel@nongnu.org; Tue, 13 Dec 2011 08:37:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RaSXS-0000Eo-KJ for qemu-devel@nongnu.org; Tue, 13 Dec 2011 08:37:02 -0500 Received: from mail-yx0-f173.google.com ([209.85.213.173]:47341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaSXS-0000Ek-GY for qemu-devel@nongnu.org; Tue, 13 Dec 2011 08:36:58 -0500 Received: by yenm6 with SMTP id m6so6373209yen.4 for ; Tue, 13 Dec 2011 05:36:58 -0800 (PST) Message-ID: <4EE754F7.3030900@codemonkey.ws> Date: Tue, 13 Dec 2011 07:36:55 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20111208174544.325838a6@doriath> <20111212155046.GB29447@garlic.tlv.redhat.com> <20111212140800.11873fa8@doriath> <4EE62B2F.4070408@codemonkey.ws> <4EE731B8.5000701@redhat.com> In-Reply-To: <4EE731B8.5000701@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Dropping the MONITOR_CMD_ASYNC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Luiz Capitulino , Alon Levy , qemu-devel , stefanha@linux.vnet.ibm.com, kraxel@redhat.com On 12/13/2011 05:06 AM, Avi Kivity wrote: > On 12/12/2011 06:26 PM, Anthony Liguori wrote: >> >> Nope, it has to be dropped. >> >> Commands using CMD_ASYNC may fail in arbitrary ways because of the way >> error reporting is done. This is an unfixable problem until we >> eliminate all uses of qerror_report(). >> > > Why don't we eliminate all uses for qerror_report() then? Breaking our > interfaces instead seems like a horrible idea. That's what Luiz is doing right now. Regards, Anthony Liguori > >> We need to take the hit here and force the command to always fail. >> libvirt will need logic to use a different command with new versions. >> If we coordinate this with the libvirt folks, we can make the >> transition as smooth as possible. > > I thought we've outgrown this. If we provide an interface, we should > support it. >