qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] vmstate: Add VMSTATE_OPAQUE to save/load comple


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] vmstate: Add VMSTATE_OPAQUE to save/load complex data structures
Date: Fri, 24 May 2019 18:29:53 +0100

On Fri, 24 May 2019 at 18:00, Roman Kiryanov <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]