From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rxey5-0001No-4M for qemu-devel@nongnu.org; Wed, 15 Feb 2012 08:32:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rxexu-0001tf-PL for qemu-devel@nongnu.org; Wed, 15 Feb 2012 08:32:21 -0500 Received: from goliath.siemens.de ([192.35.17.28]:18761) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rxexu-0001tR-8K for qemu-devel@nongnu.org; Wed, 15 Feb 2012 08:32:10 -0500 Message-ID: <4F3BB3D6.3010108@siemens.com> Date: Wed, 15 Feb 2012 14:32:06 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1328902266-25308-1-git-send-email-lcapitulino@redhat.com> <1328902266-25308-6-git-send-email-lcapitulino@redhat.com> <4F3B74BE.30802@siemens.com> <20120215105328.71e1a5b5@doriath.home> In-Reply-To: <20120215105328.71e1a5b5@doriath.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/6] 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: "aliguori@us.ibm.com" , "qemu-devel@nongnu.org" , "quintela@redhat.com" On 2012-02-15 13:53, Luiz Capitulino wrote: > On Wed, 15 Feb 2012 10:02:54 +0100 > Jan Kiszka wrote: > >> On 2012-02-10 20:31, Luiz Capitulino wrote: >>> The Monitor object is passed back and forth within the migration/savevm >>> code so that it can print errors and progress to the user. >>> >>> However, that approach assumes a HMP monitor, being completely invalid >>> in QMP. >>> >>> This commit drops almost every single usage of the Monitor object, all >>> monitor_printf() calls have been converted into DPRINTF() ones. >> >> Particularly NACK on this. Either the information is useless anyway, >> then remove it. Otherwise, keep it for channels that can properly >> display it (AKA HMP). I bet the latter can easily be achieved by >> providing non-printing Monitor objects over QMP instances. > > I will consider dropping it :) > > I can think of two ways of displaying status in HMP (considering the new > HMP/QMP split design): > > 1. We add all progress status information to a query command, and let HMP > poll it (manually by the user or automatically from a timer) As migration can also be synchronous, polling has to be time-driven. > > 2. We emit an event whenever the progress status changes (seems a bit overkill) If there is a use in QMP as well... dunno. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux