Re: [Qemu-devel] [PATCH V2 5/5] vmstate: introduce get_bufsize entry in VMStateField

[Igor Mitsyanko <i.mitsyanko@samsung.com>]

On 03/14/2012 04:55 PM, Andreas Färber wrote:
> Am 05.03.2012 09:30, schrieb Igor Mitsyanko:
>> New get_bufsize field in VMStateField is supposed to help us easily add save/restore
>> support of dynamically allocated buffers in device's states.
>> There are some cases when information about size of dynamically allocated buffer is
>> already presented in specific device's state structure, but in such a form that
>> can not be used with existing VMStateField interface. Currently, we either can get size from
>> another variable in device's state as it is with VMSTATE_VBUFFER_* macros, or we can
>> also multiply value kept in a variable by a constant with VMSTATE_BUFFER_MULTIPLY
>> macro. If we need to perform any other action, we're forced to add additional
>> variable with size information to device state structure with the only intention
>> to use it in VMStateDescription. This approach is not very pretty. Adding extra
>> flags to VMStateFlags enum for every other possible operation with size field
>> seems redundant, and still it would't cover cases when we need to perform a set of
>> operations to get size value.
>> With get_bufsize callback we can calculate size of dynamic array in whichever
>> way we need. We don't need .size_offset field anymore, so we can remove it from
>> VMState Field structure to compensate for extra memory consuption because of
>> get_bufsize addition. Macros VMSTATE_VBUFFER* are modified to use new callback
>> instead of .size_offset. Macro VMSTATE_BUFFER_MULTIPLY and VMFlag VMS_MULTIPLY
>> are removed completely as they are now redundant.
>>
>> Signed-off-by: Igor Mitsyanko<i.mitsyanko@samsung.com>
>
> Apart from this commit message being an overwhelmingly huge block of
> text ;) (maybe insert an empty line or two?)

OK :)

  this had touched on the
> overall discussion of whether to pursue a declarative or imperative
> approach for VMState.
>
> So, what about adding this as a new, optional mechanism and leaving
> VBUFFER / BUFFER_MULTIPLY users untouched?

I don't mind.

Now that we decided (in another thread) against live saving of wp_groups 
in SDState, the question with this patch arises again: do we need to 
introduce get_bufsize or we should just use additional member in SDState 
to hold wp_groups buffer size for use with current 
VMSTATE_VBUFFER_UINT32 macro?

-- 
Mitsyanko Igor
ASWG, Moscow R&D center, Samsung Electronics
email: i.mitsyanko@samsung.com