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

[Stefan Berger]

On 10/03/2011 09:43 AM, Anthony Liguori wrote:
> On 10/03/2011 08:24 AM, Michael S. Tsirkin wrote:
> > 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 if we try to fit it within a release we'll either end up with 
> a 2 year long release or a half-broken conversion.
>
> I'd rather buy ourselves time by supporting both formats.  That way we 
> can remove the old format when we're satisfied with the ASN.1 encoding.
Hm, if backwards compatibility is what we want to achieve (migrating 
from Qemu 1.1 to Qemu 1.0) then at least the ASN.1 decoder / encoder 
should be all done in 1.0, no? Otherwise what would it mean to if 1.0 
just skipped types 1.1 sends and doesn't understand?
> There are multiple things to consider with compatibility:
>
> 1) Creating compatible device models.  This is a qdev problem and 
> can't be solved in the protocol.
>
> 2) Ensuring we are sending all the data we need to.  I think we solve 
> this problem by autogenerating Visitors from the C definitions of the 
> device structures.
I would have thought that we would write a function that takes the 
VMStateDescription as an argument and write ASN.1 BER or CER comprising:
- a header containing the version of the device data
- the minimum version required to read the device data
- walk the array of VMStateFields and encode the the device data

and similarly a function for walking the fields for decoding of each 
device state.

So at least I am surprised to hear 'autogeneration' for this particular 
case...

   Stefan