qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [QEMU PATCH v5 3/6] migration: extend VMStat


From: Halil Pasic
Subject: Re: [Qemu-devel] [Qemu-ppc] [QEMU PATCH v5 3/6] migration: extend VMStateInfo
Date: Thu, 13 Oct 2016 12:48:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0


On 10/13/2016 10:22 AM, Paolo Bonzini wrote:
>>> No, I disagree.  We shouldn't be worried about making intrusive changes
>>> > > to all invocations or declarations, if that leads to a simpler API.
>> > 
>> > If VMStateInfo was meant for complete customization, then it was missing
>> > some parts. I think the API is indeed simpler. Just like
>> > definition for VMStateField. Not all of its fields are used all time.
> Code moves.  We can decide how much customization to allow of VMStateInfo.
> 
> You said it: "Not all of its fields are used all time".  Likewise, not
> all arguments are used all time for get/put, but it's not an issue if they
> are still there!  So this patch is good, but at the same time VMS_LINKED is
> pointless.
> 
> Paolo
> 

I'm fine with this. I just think, it would be nice if the contract between
the vmstate-core and the client code implementing VMStateInfo callbacks
could be documented, including when are certain parameters valid, what
they stand for, and how are they supposed to be used for the next version of
the patch. Just to improve readability. Would this be OK with everybody?

By the way the flag VMS_SINGLE is documented as ignored. Should we drop
it?


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]