From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ND14l-0002Cd-9Y for qemu-devel@nongnu.org; Tue, 24 Nov 2009 14:29:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ND14g-00027m-Hv for qemu-devel@nongnu.org; Tue, 24 Nov 2009 14:29:22 -0500 Received: from [199.232.76.173] (port=47959 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ND14g-00027P-9e for qemu-devel@nongnu.org; Tue, 24 Nov 2009 14:29:18 -0500 Received: from mail-bw0-f212.google.com ([209.85.218.212]:45116) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ND14g-0006Sy-2G for qemu-devel@nongnu.org; Tue, 24 Nov 2009 14:29:18 -0500 Received: by bwz4 with SMTP id 4so8381291bwz.2 for ; Tue, 24 Nov 2009 11:29:16 -0800 (PST) Message-ID: <4B0C3405.7030207@codemonkey.ws> Date: Tue, 24 Nov 2009 13:29:09 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts References: <4B0952C9.9010803@redhat.com> <200911241335.35334.paul@codesourcery.com> <20091124134910.GH2405@redhat.com> <200911241359.49321.paul@codesourcery.com> <20091124142152.GN2405@redhat.com> <20091124170809.GC3397@redhat.com> <4B0C1B46.90504@redhat.com> <4B0C2B40.4040803@codemonkey.ws> <4B0C2CA9.7060407@redhat.com> In-Reply-To: <4B0C2CA9.7060407@redhat.com> 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: Paolo Bonzini Cc: Blue Swirl , qemu-devel@nongnu.org, Paul Brook , "Michael S. Tsirkin" Paolo Bonzini wrote: > On 11/24/2009 07:51 PM, Anthony Liguori wrote: >>> to make the primary representation of state an XML document > > Since my brain is not working well today, I'll just point out that of > course I meant "the primary representation of _schemas_ an XML > document" or anything like that. > >>> or anything like that (and convert it back to VMState structs at build >>> time), it would not be a huge work, and it would give important >>> benefits. >> >> Like adding tremendous complexity for little to no gain. > > Anything that could result in a libqemustate or something like that > would be complex, but would have gain. (Yes, I've seen the smiley > despite aforementioned problems with the brain). Which would be...? "Increased flexibility" is not a quantifiable gain. If there's a particular feature we need to support, let's try to support the feature. There are bigger fish to fry with live migration than the protocol format. For instance, we need to do a fair bit of work to build an infrastructure that will let us test this stuff in a sane way so we can avoid introducing things like the pvclock regression. Regards, Anthony Liguori > Paolo