qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 03/26] Remove SaveVM v2 support


From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH 03/26] Remove SaveVM v2 support
Date: Fri, 11 Sep 2009 16:28:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Stefano Stabellini <address@hidden> wrote:
> On Thu, 10 Sep 2009, Anthony Liguori wrote:
>> Practically speaking, we only have the ability to support back to 
>> 0.10.0.  We simply didn't have the necessary infrastructure in place to 
>> support anything older than that.
>> v3 of the savevm protocol came before 0.10.0 so there's no need for us 
>> to every support v2 or v1 of the protocol.
>> 
>> There are some major changes happen to the savevm infrastructure for 
>> 0.12.0.  I'd suggest that instead of not removing v2, we remove it, 
>> finish up the changes, then you can look at re-adding support for it.
>> 
>> Some of the features of v2 may be difficult to carry forward (like the 
>> savevm section sizes).
>> 
>> And FWIW, I don't necessarily think we'll see a v4 for 0.12.0.  I'm not 
>> convinced it's needed and/or useful.
>> 
>
> I gave a better look at the code and the situation is not as bad as I
> thought: the important code for us is not much the single
> function qemu_loadvm_state_v2 that can easily be replaced and\or
> rewritten but all the per device state loading functions in C, that
> fortunately are shared between v2 and v3.
> I am still unhappy with removing support for v2 and I am inclined to
> consider it a regression but as long as you keep those functions in I am
> reasonably happy.

I think we can't call that a regression:

Old in the past SaveVM State v2 is created.

Everything works for a while.

At some later point SaveVM State v3 is created.

Things continue to work fo a while.

After this while (In April of this year ram support for V2 got broken, when I 
fixed
it, I found that VGA got garbled and ide didn't work either).

Things didn't work for at least 5 months, I haven't seen a complaint.

Removing something that hasn't work during 5 months and nobody
complained is supposed to be a regression?

Now: We have v2 support on tree, that is not working, haven't worked for
a long time, and there is not a chance to load an image from the old
past.  What is better?  Remove the old non working code.  Or spend time
debugging why it stopped working and fixing it?  Notice that it is also
important that nobody complained that they were unable to load the old images.

Later, Juan.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]