Re: [Qemu-stable] [PATCH 1/4] configure: Add --enable-migration-from-qemu-kvm

[Anthony Liguori]

Paolo Bonzini <address@hidden> writes:

> Il 21/02/2013 08:44, Paolo Bonzini ha scritto:
>> Il 20/02/2013 22:03, Anthony Liguori ha scritto:
>>> Paolo Bonzini <address@hidden> writes:
>>>
>>>> Il 20/02/2013 21:26, Anthony Liguori ha scritto:
>>>>> Cole Robinson <address@hidden> writes:
>>>>>
>>>>>> This switch will turn on all the migration compat bits needed to
>>>>>> perform migration from qemu-kvm to qemu. It's just a stub for now.
>>>>>>
>>>>>> This compat will break incoming migration from qemu < 1.3, but for
>>>>>> distros where qemu-kvm was the only shipped package for years it's
>>>>>> not a big loss (and I don't know any way to avoid it).
>>>>>>
>>>>>> Signed-off-by: Cole Robinson <address@hidden>
>>>>>
>>>>> This can't be a build time option.  It's ugly and just reintroduces a 
>>>>> fork.
>>>>
>>>> It is not a fork; it does not change the migration format of QEMU
>>>> itself, only the parsing of old VMState versions.  The importance of the
>>>> fork will dwindle over time, as the distros EOL the releases that used
>>>> qemu-kvm.
>>>
>>> Once a distro enables CONFIG_QEMU_KVM, it must keep it enabled forever.
>>> So the distros will contineut o do CONFIG_QEMU_KVM whereas upstream does
>>> not set it.  It's a fork all within the same tree.
>> 
>> They will set it for a while.  For example, F18 is the last Fedora
>> release that had qemu-kvm < 1.3.0.  As soon as F18 goes end-of-life
>> (which is with F21), Fedora will not need to set the configure option
>> anymore.
>> 
>> Of course other distros will keep it for years rather than months, but
>> the idea is the same.
>> 
>>> What about having something processed by readconfig that wasn't disabled
>>> by -nodefaults?  Then we could make it a runtime option, but that's
>>> configurable globally.  Then the distros can choose the default value in
>>> the config file.
>>>
>>> At least then, we can write unit tests with the option at run time,
>>> don't need to sprinkle #ifdefs everywhere, etc.
>> 
>> That would make sense, but it shouldn't block this patch.  What would
>> happen otherwise is that distros (who care about migration
>> compatibility) will just patch their code without even the #ifdefs.
>> It's already happening, these patches are in F18.
>
> Ping, where do we stand here?  Shall we discuss it next Tuesday?

My only requirement for this patch series is that it *also* be made to
be dynamically configurable.  This should be toggable with a command
line option and the default can be set by configure.

At least that makes it testable with make check.

Regards,

Anthony Liguori

>
> Paolo