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.mitsya...@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.mitsya...@samsung.com
