> > 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.

Code moves.  We can decide how much customization to allow of VMStateInfo.

You said it: "Not all of its fields are used all time".  Likewise, not
all arguments are used all time for get/put, but it's not an issue if they
are still there!  So this patch is good, but at the same time VMS_LINKED is


> > 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.
> > Paolo
> > 
> Thanks,
> Jianjun

Reply via email to