Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format

[Luiz Capitulino <lcapitulino@redhat.com>]

On Mon, 01 Aug 2011 08:53:28 -0500
Anthony Liguori <anthony@codemonkey.ws> 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
>