From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MloIW-0002T5-Bb for qemu-devel@nongnu.org; Thu, 10 Sep 2009 14:23:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MloIR-0002Lr-Lk for qemu-devel@nongnu.org; Thu, 10 Sep 2009 14:23:07 -0400 Received: from [199.232.76.173] (port=40840 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MloIR-0002Lc-BB for qemu-devel@nongnu.org; Thu, 10 Sep 2009 14:23:03 -0400 Received: from mail-yw0-f203.google.com ([209.85.211.203]:40400) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MloIQ-0000lu-UE for qemu-devel@nongnu.org; Thu, 10 Sep 2009 14:23:03 -0400 Received: by ywh41 with SMTP id 41so507865ywh.19 for ; Thu, 10 Sep 2009 11:23:02 -0700 (PDT) Message-ID: <4AA94403.5020500@codemonkey.ws> Date: Thu, 10 Sep 2009 13:22:59 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 03/26] Remove SaveVM v2 support References: <9e1839178f7a85d264eee20a07d4aed6e6ddb7b1.1252543871.git.quintela@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: "qemu-devel@nongnu.org" , Juan Quintela Stefano Stabellini wrote: > First of all sorry if I come late into the discussion but I was on > vacation. > > We just need the loading function and we don't even need the ram loading > portion of it but just the device state loading. Of course for qemu > doesn't make sense to keep only the device loading function around > therefore I suggested to keep it all and fix it instead. > > As I have mentioned before I think it is really important to provide > backward compatibility, and we do in xen and xenserver without too much > trouble. > I am willing to send patches to fix the device state loading functions, > and we might already have few fixes in qemu-xen. > > I realize that my use case is off the tree so you have all the rights > not to be interested in it, nonetheless I hope you don't completely > discard it because it would make our life difficult. > 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. Regards, Anthony Liguori