From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37952) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ra8i2-0004BM-A0 for qemu-devel@nongnu.org; Mon, 12 Dec 2011 11:26:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ra8hv-0006Cl-AT for qemu-devel@nongnu.org; Mon, 12 Dec 2011 11:26:34 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]:38631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ra8hu-0006Cd-PK for qemu-devel@nongnu.org; Mon, 12 Dec 2011 11:26:26 -0500 Received: by qcsd15 with SMTP id d15so4373130qcs.4 for ; Mon, 12 Dec 2011 08:26:26 -0800 (PST) Message-ID: <4EE62B2F.4070408@codemonkey.ws> Date: Mon, 12 Dec 2011 10:26:23 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20111208174544.325838a6@doriath> <20111212155046.GB29447@garlic.tlv.redhat.com> <20111212140800.11873fa8@doriath> In-Reply-To: <20111212140800.11873fa8@doriath> 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: Luiz Capitulino Cc: Alon Levy , kraxel@redhat.com, stefanha@linux.vnet.ibm.com, qemu-devel On 12/12/2011 10:08 AM, Luiz Capitulino wrote: > On Mon, 12 Dec 2011 17:50:46 +0200 > 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... >>> >> >> Why has it got to be dropped? can't it be declared as deprecated first? > > Well, after this thread looks like it's what we'll have to do...\ 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(). 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. Regards, Anthony Liguori > >> >>> 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? :) >>> >> > >