[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migrati
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format |
Date: |
Thu, 4 Aug 2011 11:59:25 -0300 |
On Mon, 01 Aug 2011 08:53:28 -0500
Anthony Liguori <address@hidden> 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
>