[Top][All Lists]

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

Re: [Qemu-devel] [QEMU RFC PATCH v3 4/6] Migration: migrate QTAILQ

From: Jianjun Duan
Subject: Re: [Qemu-devel] [QEMU RFC PATCH v3 4/6] Migration: migrate QTAILQ
Date: Thu, 2 Jun 2016 09:11:18 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

Hi Sascha,

On 06/02/2016 08:01 AM, Sascha Silbe wrote:
> Dear Jianjun,
> Jianjun Duan <address@hidden> writes:
> [include/migration/vmstate.h]
>> @@ -185,6 +185,8 @@ enum VMStateFlags {
>>       * to determine the number of entries in the array. Only valid in
>>       * combination with one of VMS_VARRAY*. */
>>      VMS_MULTIPLY_ELEMENTS = 0x4000,
>> +    /* For fields which need customized handling, such as QTAILQ in 
>> queue.h*/
>> +    VMS_CSTM            = 0x8000,
> Can you describe (in the comment) how this customised handling is
> performed, please? I.e. describe what exactly happens if the flag is
> set, from the point of view of an API consumer.

I will add more comments. When this flag is set VMStateInfo.get/put will
be used in vmstate_load/save_state instead of recursive call. And the
user should implement VMStateInfo.get/put to handle the concerned data
> Also, why do you need this flag at all? The only change I can see is
> that you pass additional information to VMStateInfo.get() / .put(),
> using NULL if it's not set. Why don't you just always pass the
> additional information? If the additional information is not needed by
> get() / put() the parameter will be unused anyway.
You can do it without creating this flag. Instead just to check if info
is set in the field. However I think it is more readable and more robust
to check this flag in vmstate_load/get_state.
> Sascha


reply via email to

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