On Fri, 24 May 2019 at 18:00, Roman Kiryanov <r...@google.com> wrote: > > Hi Peter, > > > In any case, migration state on the wire needs to be > > architecture/endianness/ > > Could you please point how the proposed change is > architecture/endianness/ dependent?
That's really hard to say, because this patch doesn't come with any example of its use. So I'm basically guessing that when you say "load/save complex data structures" and call your macro OPAQUE that you mean "I am going to just feed the raw in-memory representation of this data structure into the migration stream in an opaque way". Perhaps my assumptions here are wrong ? > > implementation-independent, > > Could you please elaborate, what "implementation" > you mean here? I had in mind the C++ implementation of unordered_map<>. > > so you can't just send raw complex data structures > > Do we need to serialize (in pre_save and then release in > post_save) our state into a buffer and to write it as one > piece using the existing macro? This looks ok, but how > is this different from what we are doing? I guess essentially what I'm asking for here is that this patch comes as part of a series which makes use of it. It's really hard to evaluate the design of a utility feature without a concrete example of how it's being used. That then makes it easier to understand the abstract feature and also allows us to sometimes suggest better ways to achieve the underlying aim (and to avoid making suggestions which don't make sense!) A corollary of this is that in general we don't like to take patches upstream that implement facilities that don't have a use upstream. Is there some existing vmstate handling in upstream QEMU that we could refactor to be more cleanly implemented using this? thanks -- PMM