Re: [Qemu-devel] [PATCH v4 24/26] qidl: add QAPI-based code generator

[Michael Roth <mdroth@linux.vnet.ibm.com>]

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
> >