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