On 10/12/2016 02:07 PM, 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.

Paolo I agree on a theoretical level. It's just I do not see why this
particular change makes the API simpler. In my opinion this complicates
things because now all VMStateInfo's can do funky stuff. Having additional
state you can poke is rarely a simplification. Same goes for lots
of arguments especially if some of them are barely ever used. These
additional parameters contribute nothing for the large majority
of the cases (except maybe some head scratching when reading
the code).

No strong opinion here, it's just that I don't understand. I think one
trait of a simple API is that it is easy to document. Unfortunately
the documentation is quite sparse and in the patch the signature
change goes undocumented.

Well as I said, just an idea, motivated by how I understood he role of
VMStateInfo form reading the code.


Reply via email to