From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qnf9h-00058T-CG for qemu-devel@nongnu.org; Sun, 31 Jul 2011 19:10:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qnf9g-0002J0-A3 for qemu-devel@nongnu.org; Sun, 31 Jul 2011 19:10:45 -0400 Received: from verein.lst.de ([213.95.11.211]:53307 helo=newverein.lst.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qnf9g-0002Im-4J for qemu-devel@nongnu.org; Sun, 31 Jul 2011 19:10:44 -0400 Date: Mon, 1 Aug 2011 01:10:42 +0200 From: Christoph Hellwig Message-ID: <20110731231042.GA18311@lst.de> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E35BE5C.9040607@redhat.com> 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: Dor Laor Cc: Kevin Wolf , Peter Maydell , Stefan Hajnoczi , mst@redhat.com, Ryan Harper , quintela@redhat.com, qemu-devel@nongnu.org, Paolo Bonzini , Christoph Hellwig 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.