On 10/13/2016 10:22 AM, Paolo Bonzini wrote: >>> 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'm fine with this. I just think, it would be nice if the contract between the vmstate-core and the client code implementing VMStateInfo callbacks could be documented, including when are certain parameters valid, what they stand for, and how are they supposed to be used for the next version of the patch. Just to improve readability. Would this be OK with everybody? By the way the flag VMS_SINGLE is documented as ignored. Should we drop it?
signature.asc
Description: OpenPGP digital signature