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 size
>> and provide a new anchor for documentation
>> * if overloading the semantic of VMStateField.start is not desired we
>> could put it into VMStateLinked, if needed we could also put more
>> stuff in there
>> * have clearer separation between special handling for (linked/certain)
>> data structures and the usual scenario with the DAG.
> 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 for VMStateField. Not all of its fields are used all time.
> I agree that overloading .start can be a bit ugly but you can choose to
> overload .num_offset instead, which is already better.
I did considered num_offset. But it is associated with an actual field.
On the other hand, start means the start position of the q in the
structure. So it is not that far stretched.
>> I would also suggest unit tests in test/test-vmstate.c. Maybe with
>> that the vmstate migration of QTAILQ could be factored out as a separate
>> patch series.
> Yes, definitely.
This sounds a good idea. Will do it.