From: Juan Quintela <quintela@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: [PATCH 03/26] Remove SaveVM v2 support
Date: Fri, 11 Sep 2009 16:28:29 +0200 [thread overview]
Message-ID: <m31vmd8sj6.fsf@neno.mitica> (raw)
In-Reply-To: <alpine.DEB.2.00.0909111500560.2687@kaball-desktop> (Stefano Stabellini's message of "Fri, 11 Sep 2009 15:05:51 +0100")
Stefano Stabellini <stefano.stabellini@eu.citrix.com> 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.
next prev parent reply other threads:[~2009-09-11 14:31 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-10 1:04 [Qemu-devel] [PATCH 00/26] VMState: port several pc devices to vmstate Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 01/26] ram: remove support for loading v1 Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 02/26] ram: Remove SaveVM Version 2 support Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 03/26] Remove SaveVM v2 support Juan Quintela
2009-09-10 17:41 ` Stefano Stabellini
2009-09-10 17:43 ` [Qemu-devel] " Juan Quintela
2009-09-10 18:15 ` Stefano Stabellini
2009-09-10 18:22 ` Anthony Liguori
2009-09-11 14:05 ` Stefano Stabellini
2009-09-11 14:28 ` Juan Quintela [this message]
2009-09-11 15:32 ` Stefano Stabellini
2009-09-11 15:37 ` Anthony Liguori
2009-09-11 15:48 ` Juan Quintela
2009-09-11 17:59 ` Stefano Stabellini
2009-09-17 11:40 ` Stefano Stabellini
2009-09-10 1:04 ` [Qemu-devel] [PATCH 04/26] timers: remove useless check Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 05/26] Unexport ticks_per_sec variable. Create get_ticks_per_sec() function Juan Quintela
2009-09-10 1:20 ` malc
2009-09-10 1:57 ` [Qemu-devel] " Juan Quintela
2009-09-10 2:21 ` malc
2009-09-10 16:44 ` Juan Quintela
2009-09-10 17:02 ` malc
2009-09-10 17:38 ` Anthony Liguori
2009-09-10 21:31 ` malc
2009-09-10 22:08 ` Anthony Liguori
2009-09-10 23:10 ` malc
2009-09-10 23:33 ` Juan Quintela
2009-09-11 5:49 ` Amit Shah
2009-09-11 13:00 ` Markus Armbruster
2009-09-11 15:34 ` Anthony Liguori
2009-09-11 15:55 ` Juan Quintela
2009-09-11 15:58 ` Jan Kiszka
2009-11-09 16:29 ` Paul Brook
2009-09-10 17:39 ` Juan Quintela
2009-09-10 22:16 ` Paolo Bonzini
2009-09-10 23:11 ` malc
2009-09-11 9:04 ` Jan Kiszka
2009-09-11 9:31 ` Juan Quintela
2009-09-11 9:37 ` Jan Kiszka
2009-09-11 10:15 ` Juan Quintela
2009-09-11 10:26 ` Jan Kiszka
2009-09-10 1:04 ` [Qemu-devel] [PATCH 06/26] timers: Createt TimersState and put all timers state there Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 07/26] timers: move them to VMState Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 08/26] vmstate: add sensible arguments to vmstate_unregister() Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 09/26] vmstate: rename run_after_load() -> post_load() Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 10/26] vmstate: Add pre_load() hook Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 11/26] vmstate: Add pre/post_save() hooks Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 12/26] vmstate: port cpu_comon Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 13/26] vmstate: port fw_cfg device Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 14/26] vmstate: port i8259 device Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 15/26] vmstate: add support for uint8_t equal Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 16/26] vmstate: port fdc device Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 17/26] vmstate: add support for arrays of uint16_t Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 18/26] vmstate: port dma device Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 19/26] vmstate: port vmmouse device Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 20/26] vmstate: port pckbd device Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 21/26] vmstate: add uint64 array support Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 22/26] vmstate: port ioapic device Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 23/26] hpet: it is imposible that qemu_timer field is NULL at this point Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 24/26] vmstate: port hpet device Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 25/26] vmstate: port serial device Juan Quintela
2009-09-10 1:04 ` [Qemu-devel] [PATCH 26/26] vmstate: port cirrus_vga device Juan Quintela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m31vmd8sj6.fsf@neno.mitica \
--to=quintela@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).