Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface

[Michael S. Tsirkin]

On Mon, Oct 03, 2011 at 07:51:00AM -0500, Anthony Liguori wrote:
> >Here are some suggestions:
> >
> >- Let's make the protocol be BER directly.
> >   As a first step, use a single octet string for
> >   the whole of data. Next, start splitting this up.
> 
> This can't be done without breaking the old style migration
> protocol.  I don't have a problem with that but I do have a problem
> with repeatedly breaking migration protocol.

As long as this is within a release cycle, is this a real problem?

I think switching to BER then imediately releasing will be
a mistake. Let's switch, iron out bugs and add features.

> The Visitor interface is very little abstraction over a native BER
> interface. It lets us introduce BER incrementally while still
> supporting the old protocol.
> 
> >
> >- Don't try to use arrays at all. They don't make sense
> >   in either jason or asn. Instead, use sets for unordered
> >   data and sequences for ordered data.
> 
> sequences map to visit_start_array() pretty well. You would do something like:
> 
> visit_start_array(v, "entries", errp);
> for (int i = 0; i < s->size; i++) {
>     visit_type_int(v, NULL, &s->entry[i], errp);
> }
> visit_end_array(v, errp);

Sequences can encode structures not just arrays.
How would you encode this for example:

SEQUENCE OF { VQN: INTEGER, SEQUENCE { OPTIONAL VECTOR: INTEGER}  }

This is a natural description of a virtio device.

Yes we can unwrap this to a structure of arrays but
this is tweaking protocol to match implementation.


> >- Most data should be unordered: we don't normally care
> >   in which order we get device attributes.
> >   So we would have set of sequences, and
> >   each sequence is attribute name (ascii string) + attribute data
> 
> I'd actually be inclined to make everything ordered by default and
> not encode explicit field names.  I'm afraid that encoding field
> names on the wire is going to easily increase the amount of device
> state by an order of magnitude.

Assuming we worry about space used by name tags, let's use
content-specific tags.

> >- This does not discuss how we will handle cross version
> >   migration in a lot of detail. Presumably you expect capability magic to
> >   work for this. However this does not work for migration to file.
> >   A self describing format makes a much simpler solution possible:
> >   separating attributes which destination must parse from those
> >   it can skip safely. If destination sees an attribute
> >   that was marked as must parse and does not recognize it,
> >   migration fails. If not, just skip the attribute.
> 
> Compatibility and the wire format are more or less orthogonal.  A
> self describing format helps eliminate a class of bugs but getting
> compatibility right requires quite a bit more.
> 
> Regards,
> 
> Anthony Liguori

So I think we do care about compatibility.
I think this is by far the most interesting part of the problem.
And making that robust IMO pretty much requires not relying
on field order whenever we are not absolutely sure
no other order makes sense.

Content-specific tags as suggested above let us do unordered.
We lose the ability to easily examine
input by external tools but without field names
they won't be able to parse it so it's not all that valuable anyway.


-- 
MST