From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MAmAP-000093-GK for qemu-devel@nongnu.org; Sun, 31 May 2009 10:37:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MAmAK-00007L-1w for qemu-devel@nongnu.org; Sun, 31 May 2009 10:37:41 -0400 Received: from [199.232.76.173] (port=39930 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAmAJ-00007E-Rk for qemu-devel@nongnu.org; Sun, 31 May 2009 10:37:35 -0400 Received: from mx2.redhat.com ([66.187.237.31]:52403) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MAmAJ-0003fD-6w for qemu-devel@nongnu.org; Sun, 31 May 2009 10:37:35 -0400 Message-ID: <4A2295CE.309@redhat.com> Date: Sun, 31 May 2009 17:35:58 +0300 From: Dor Laor 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> In-Reply-To: <1243590193.13990.73.camel@blaa> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark McLoughlin Cc: Anthony Liguori , ajax@redhat.com, Paul Brook , qemu-devel@nongnu.org Mark McLoughlin wrote: > On Fri, 2009-05-29 at 00:45 +0300, Dor Laor wrote: > > >> Nevertheless, as Anthony states, guest ABI should be rock stable. >> We should have mechanism (machine conf format++) that will enable us >> to configure pci addresses, cpuid entries, memory layout, device >> existence (hpet, virtio-console,..), etc. >> >> Anyhow, I did sent a patch to allow virtio block to parametrized class >> value - >> http://lists.gnu.org/archive/html/qemu-devel/2009-05/msg01189.html >> There wasn't a perfect match with finding the right interface to change >> it, happy to hear >> other alternatives if you're not happy with it. >> > > As I said, it's pointless to add something like this if, realistically, > it will never be used. > > So, taking the example of '-drive class=foo' ... a user who runs qemu > directly would have to know that when she updates from qemu-0.10.x to > qemu-0.11.x, she needs to use '-drive class=384' for ever more. I find > it hard to believe anyone will ever do that. > 'She' is not a user, she is a developer. Users use management tools like libvirt below. Running qemu directly is complicated and error prone for manual/human users. I just wanted to stress this out, more feedback in the next email. > Perhaps management tools can hide this complexity? In order to do this > in libvirt, we'd need to do the following: >