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
