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

[Igor Mitsyanko]

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<address@hidden>
>
> 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: address@hidden