From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QngAI-0006o4-EA for qemu-devel@nongnu.org; Sun, 31 Jul 2011 20:15:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QngAH-00049h-Hl for qemu-devel@nongnu.org; Sun, 31 Jul 2011 20:15:26 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:53362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QngAH-00049d-EZ for qemu-devel@nongnu.org; Sun, 31 Jul 2011 20:15:25 -0400 Received: by yia25 with SMTP id 25so3848202yia.4 for ; Sun, 31 Jul 2011 17:15:24 -0700 (PDT) Message-ID: <4E35F019.5060908@codemonkey.ws> Date: Sun, 31 Jul 2011 19:15:21 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E2EB522.2000808@codemonkey.ws> <4E32BD96.9030806@redhat.com> <4E32C385.5020702@codemonkey.ws> <4E32CF52.9080203@redhat.com> <4E33340D.5050003@codemonkey.ws> <4E353314.8070403@redhat.com> <4E354043.6050203@redhat.com> <20110731184625.GA14622@lst.de> <4E35BE5C.9040607@redhat.com> <20110731231042.GA18311@lst.de> In-Reply-To: <20110731231042.GA18311@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Kevin Wolf , Peter Maydell , Stefan Hajnoczi , mst@redhat.com, Ryan Harper , Dor Laor , qemu-devel@nongnu.org, quintela@redhat.com, Paolo Bonzini On 07/31/2011 06:10 PM, Christoph Hellwig wrote: > On Sun, Jul 31, 2011 at 11:43:08PM +0300, Dor Laor wrote: >> /me caught off guard. I wonder why it wasn't converted to VMSTATE before? >> virtio is one of the key devices, it's not just random forgotten one that >> might not care about migration. > > It just shows the extent of incomplete transitions in qemu. Given how > much burden incomplete transitions have on software projects we should > try to minimize them in qemu. That is if people add a new API we need > to have a clear roadmap when it's going to be finished, and more importantly > what the consequence of not finishing it are instead of leaving it half > done. I think the way the Linux kernel handles API transitions is something > qemu could borrow from. For most of them it's simply expected to do a simple > conversion of all users of an API to the new equivalent, maybe it in > simplistic and dumb way, but at least a transition. Combined with a > deprectation schedule for unused drivers that seems to do wonders, although > of course even the Linux kernel is slacking in some areas. One of the things I think the kernel is good at, is making relatively large changes outside of the tree and then merging it in a way that makes sense when it makes sense. I think we've set the bar too low historically for introducing new interfaces. I think Avi's new memory API is a good example of how we should approach these things--do the vast majority of the thankless work up front before initial merge. Besides making sure we don't have incomplete interfaces, it also helps validate the interface before committing to it. Regards, Anthony Liguori > >