On 10/13/2016 09:32 AM, Halil Pasic wrote:
>
>
> On 10/13/2016 06:23 PM, Jianjun Duan wrote:
>>
>>
>> On 10/13/2016 03:48 AM, Halil Pasic wrote:
>>>
>>>
>>> On 10/13/2016 10:22 AM, Paolo Bonzini wrote:
>> No, I disagree. We shouldn't be worried about making intrusive changes
to
On 10/13/2016 06:23 PM, Jianjun Duan wrote:
>
>
> On 10/13/2016 03:48 AM, Halil Pasic wrote:
>>
>>
>> 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
On 10/13/2016 03:48 AM, Halil Pasic wrote:
>
>
> 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
On 13/10/2016 12:48, Halil Pasic wrote:
>> >
> 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
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
> > 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
On 10/12/2016 05:07 AM, Paolo Bonzini wrote:
>
>
> On 12/10/2016 13:59, Halil Pasic wrote:
>> IMHO this would:
>> * allow us to keep the good old MVStateInfo objects unmodified and
>> the semantic of VMStateInfo unchanged
>> * make clear that VMStateLinked does not care about the calculated
On Fri, Oct 07, 2016 at 07:42:12PM +0100, Dr. David Alan Gilbert wrote:
> * Jianjun Duan (du...@linux.vnet.ibm.com) wrote:
> >
> >
> > On 10/07/2016 05:08 AM, Dr. David Alan Gilbert wrote:
> > > * Jianjun Duan (du...@linux.vnet.ibm.com) wrote:
> > >> Current migration code cannot handle some
* Jianjun Duan (du...@linux.vnet.ibm.com) wrote:
>
>
> On 10/07/2016 05:08 AM, Dr. David Alan Gilbert wrote:
> > * Jianjun Duan (du...@linux.vnet.ibm.com) wrote:
> >> Current migration code cannot handle some data structures such as
> >> QTAILQ in qemu/queue.h. Here we extend the signatures of
On 10/07/2016 05:08 AM, Dr. David Alan Gilbert wrote:
> * Jianjun Duan (du...@linux.vnet.ibm.com) wrote:
>> Current migration code cannot handle some data structures such as
>> QTAILQ in qemu/queue.h. Here we extend the signatures of put/get
>> in VMStateInfo so that customized handling is
10 matches
Mail list logo
