On Mon, Oct 15, 2012 at 11:35:46AM -0500, Michael Roth wrote:
> On Mon, Oct 15, 2012 at 03:08:51PM +0200, Paolo Bonzini wrote:
> > Il 15/10/2012 10:12, Paolo Bonzini ha scritto:
> > > Il 12/10/2012 23:11, Michael Roth ha scritto:
> > >> + elif field['type'].startswith('enum '):
> > >> + typename = 'int'
> > >
> > > Note that there is support for enum properties in qdev. Please consider
> > > adding it, though it can be done as a follow-up.
> > >
> > > I'm going to play a bit with the series and convert 1 or 2 devices
> > > myself to see how it looks, then I'll give my acked-by.
> >
> > Ok, so now I played with it a bit. My main comments, which can all be
> > tackled as a follow-up, are:
> >
> > - immutable/derived/broken/elsewhere (and the default, let's call it
> > serialized) are really five cases of the same QIDL property. Perhaps
> > this could be enforced in the extended syntax like this:
> >
> > #define q_immutable QIDL(serialize(immutable))
> > #define q_derived QIDL(serialize(derived))
> > #define q_broken QIDL(serialize(broken))
> > #define q_elsewhere QIDL(serialize(elsewhere))
> >
> > I would also make it possible to explicitly specify the fifth state, if
> > only for symmetry.
>
> Agreed, that's a more proper grouping. Though, for consistency with
> QIDL(property, ...), I would do QIDL(serialize, ...)
>
Er, meant to respond to this in my previous reply:
> >
> > I'm not sure what your plans are for q_derived vs. VMState. If a field
> > X is set in pre_save hooks based on field Y, how should the fields be
> > set? X is usually not up-to-date, so it should be q_derived. But Y
> > cannot be serialized as is, so it should be q_elsewhere. One of the
> > two is wrong, which one? :)
Why is it that Y can't be serialized as is in this example? X's
derived state depends on it, so Y should be serialized in some form.
Are you referring to a case where VMState sets/sends X currently, but
not Y?
If so, my goal is that serialization is done properly and independently
of VMState. Then, for migration, we serialize it into a QObject (state_obj)
from which a VMState-compatible QObject (wire_obj) can be built and fed to
the wire (either via modified/re-interpreted VMSD, or a re-modeling of the
VMSD into a wire schema (possibly automagically via QIDL at first) from
which a savevm visitor could be generated).
So, for example, a post_serialize() migration hook would have access to an
up-to-date Y in the state_obj, since:
a) Y is up-date (by virtue of not being q_derived).
b) Y is q_elsewhere, but our post_serialize() hook has (or can be
given) access to the Object* that serializes Y, since we're able to
obtain a pointer to it or one of it's members.
One exception might be that we send X unecessarilly, since it's derived
from Y which is actually q_immutable, but there's no restriction that
q_immutable fields cannot be marked as, say, q_default, so we can add
those in.
Hopefully in most cases the mapping from state_obj <-> wire_obj is
trivial though and is little more than a qdict_copy(), but we can make
the mapping from state_obj <-> wire_obj as flexible as we need to cover
these cases, and potentially other compatibility requirements.
> >
> > Paolo
> >
