From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QozOa-0007Jg-U7 for qemu-devel@nongnu.org; Thu, 04 Aug 2011 10:59:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QozOZ-0005W8-MS for qemu-devel@nongnu.org; Thu, 04 Aug 2011 10:59:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26249) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QozOZ-0005W0-8z for qemu-devel@nongnu.org; Thu, 04 Aug 2011 10:59:35 -0400 Date: Thu, 4 Aug 2011 11:59:25 -0300 From: Luiz Capitulino Message-ID: <20110804115925.0445bb8b@doriath> In-Reply-To: <4E36AFD8.5090104@codemonkey.ws> References: <4E32C385.5020702@codemonkey.ws> <4E32CF52.9080203@redhat.com> <4E33340D.5050003@codemonkey.ws> <4E353314.8070403@redhat.com> <4E354043.6050203@redhat.com> <20110731184625.GA14622@lst.de> <4E35BE5C.9040607@redhat.com> <20110731231042.GA18311@lst.de> <4E35F019.5060908@codemonkey.ws> <20110801075403.GA23927@lst.de> <4E36AFD8.5090104@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Peter Maydell , Stefan Hajnoczi , mst@redhat.com, Ryan Harper , Dor Laor , qemu-devel@nongnu.org, quintela@redhat.com, Paolo Bonzini , Christoph Hellwig On Mon, 01 Aug 2011 08:53:28 -0500 Anthony Liguori wrote: > On 08/01/2011 02:54 AM, Christoph Hellwig wrote: > > On Sun, Jul 31, 2011 at 07:15:21PM -0500, Anthony Liguori wrote: > >> I think we've set the bar too low historically for introducing new > >> interfaces. I think Avi's new memory API is a good example of how we > >> should approach these things--do the vast majority of the thankless work up > >> front before initial merge. > > > > Yes, that seems to work a bit better. > > > > So how will we sort out and finalized the vmstate bits, > > http://wiki.qemu.org/Features/Migration/Next > > Is what I think we need to do next for migration. In terms of VMState, > I think we should can leave it in the current state its in for now. If > there is a desire to keep converting devices, that would be fine. > > Because I think the next thing to do in terms of changing device > serialization is to make serialization a proper virtual method of the > base object class. I think devices that use composition should also > serialize their children as part of their serialization. > > I think that falls under the banner of updating the object model. > > > QMP, and making > > sure we have one sort of error reporting? > > I've updated the QMP merge plan on the wiki: > > http://wiki.qemu.org/Features/QAPI#Merge_Plan Something that delays a full QMP conversion is designing the new interfaces (sometimes internal ones too). I feel that we're striving for perfection. While it's obvious that we need good interfaces, we have tons of commands and properly designing each of them will take ages. > We've merged phase one, and phase two shouldn't be that hard to merge as > the code is already written. It's just a matter of rebasing and > incorporating in an incremental fashion. > > Phase two eliminates qerror_report() in favor of passing Error **s. > It's very invasive which is why we decided to merge in two phases. > > Regards, > > Anthony Liguori >