From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MAm81-0007uf-2Z for qemu-devel@nongnu.org; Sun, 31 May 2009 10:35:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MAm7v-0007ti-Fj for qemu-devel@nongnu.org; Sun, 31 May 2009 10:35:11 -0400 Received: from [199.232.76.173] (port=39870 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAm7v-0007td-Cb for qemu-devel@nongnu.org; Sun, 31 May 2009 10:35:07 -0400 Received: from mx2.redhat.com ([66.187.237.31]:45119) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MAm7u-0002i0-Rr for qemu-devel@nongnu.org; Sun, 31 May 2009 10:35:07 -0400 Message-ID: <4A229511.8000907@redhat.com> Date: Sun, 31 May 2009 17:32:49 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Change virtio-console to PCI_CLASS_SERIAL_OTHER References: <1243012478.29542.18.camel@blaa> <200905281353.50463.paul@codesourcery.com> <4A1E8A16.3060101@us.ibm.com> <200905281422.52420.paul@codesourcery.com> <4A1E91AF.9050907@us.ibm.com> <4A1F05DE.6060806@redhat.com> <1243590193.13990.73.camel@blaa> <4A1FAFF7.3080808@us.ibm.com> In-Reply-To: <4A1FAFF7.3080808@us.ibm.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: Anthony Liguori Cc: Mark McLoughlin , dlaor@redhat.com, ajax@redhat.com, Paul Brook , qemu-devel@nongnu.org Anthony Liguori wrote: > Mark McLoughlin wrote: > >> On Fri, 2009-05-29 at 00:45 +0300, Dor Laor wrote: >> >> The more I think about it, no matter how much linear ABI versioning >> sucks, it's possibly the only way to solve this in a reasonably usable >> manners. Distros would just have to suck it up and agree that if they >> cherry-pick an ABI changing patch, they must update the entire ABI to >> the newer upstream ABI version. >> >> > > Can we somehow utilize the save/restore versioning infrastructure? I > think the general idea of universally versioning devices is not a bad > one but I'm not sure whether we need an additional version id or whether > we can just piggy back on the savevm version. > The savevm version can be updated due to fixes in the savevm protocol that don't affect the guest visible information at all. -- error compiling committee.c: too many arguments to function