From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44424) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S76XA-0003ZM-Ev for qemu-devel@nongnu.org; Mon, 12 Mar 2012 10:47:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S76X8-0007cg-K8 for qemu-devel@nongnu.org; Mon, 12 Mar 2012 10:47:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31971) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S76X8-0007cR-Bc for qemu-devel@nongnu.org; Mon, 12 Mar 2012 10:47:34 -0400 Message-ID: <4F5E0D58.7070001@redhat.com> Date: Mon, 12 Mar 2012 15:51:04 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1331316786-7752-1-git-send-email-lcapitulino@redhat.com> <1331316786-7752-4-git-send-email-lcapitulino@redhat.com> <4F5A4A08.8030805@siemens.com> <20120309153019.32846104@doriath.home> <4F5A5463.9010803@siemens.com> <4F5A562B.8000109@us.ibm.com> <20120309164810.28dfb64b@doriath.home> <20120309165721.38070eda@doriath.home> In-Reply-To: <20120309165721.38070eda@doriath.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/4] Purge migration of (almost) everything to do with monitors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Jan Kiszka , Anthony Liguori , "quintela@redhat.com" , "qemu-devel@nongnu.org" , "pbonzini@redhat.com" Am 09.03.2012 20:57, schrieb Luiz Capitulino: > On Fri, 9 Mar 2012 16:48:10 -0300 > Luiz Capitulino wrote: > >>> It's certainly possible to make the synchronous monitor command spit out status >>> as it already uses a polling loop to determine when migration completes. >> >> As HMP now uses QMP as a real client, we'd have to make that information >> available for all QMP users. Best place is probably query-migrate. >> >> Don't you prefer to drop the whole thing instead? :-) > > Oh, we actually have block migration information in query-migrate already, > maybe we can use that to have a progress bar (not sure it's the same info > used by current progress bar though). > > But dropping it is still a viable alternative :) We should use the decoupling of the human monitor to make it better rather than worse. :-) Kevin