On Wed, Oct 05, 2011 at 07:54:21AM -0500, Anthony Liguori wrote: > On 10/04/2011 09:05 PM, Stefan Berger wrote: > >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? > > Before we introduce ASN1, we ought to introduce migration > capabilities.
FWIW we introduce it for tpm as first step. > Migration capabilities would be used to negotation > ASN.1 over the wire. I'm not yet really convinced we need capabilities at all. Would be sad to make asn depend on that. > That means that 1.1 would use the existing > protocol to talk to 1.0. We basically never had qemu that can talk across versions 100%. The compability we carry around is so much dead code. And no wonder: there's no way to parse the protocol without being bug for bug compatible. IMO let's just switch to a sane protocol first. Being compatible with that will be much easier. > >>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 > > Sort of. You modify VMStateInfo to accept a visitor and name > parameter in load and put. Then you write an ASN.1 BER Visitor and > pass that visitor to VMStateInfo->load/put. > > Regards, > > Anthony Liguori > > > > >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
