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