From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KXcyu-0007ef-4t for qemu-devel@nongnu.org; Mon, 25 Aug 2008 10:23:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KXcys-0007bo-5E for qemu-devel@nongnu.org; Mon, 25 Aug 2008 10:23:43 -0400 Received: from [199.232.76.173] (port=57840 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KXcyr-0007ba-Tw for qemu-devel@nongnu.org; Mon, 25 Aug 2008 10:23:41 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]:51230) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KXcyr-0002GY-MJ for qemu-devel@nongnu.org; Mon, 25 Aug 2008 10:23:41 -0400 Received: by wr-out-0506.google.com with SMTP id c46so1596936wra.18 for ; Mon, 25 Aug 2008 07:23:41 -0700 (PDT) Message-ID: <48B2C03E.4060700@codemonkey.ws> Date: Mon, 25 Aug 2008 09:22:54 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/6] Add UUID command-line option References: <20080824113258.5652.92531.stgit@gleb-debian.qumranet.com.qumranet.com> <20080824122423.GA6192@minantech.com> <48B15D87.9000000@qumranet.com> <48B16860.5010207@qumranet.com> <48B27C10.3000009@qumranet.com> In-Reply-To: <48B27C10.3000009@qumranet.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Avi Kivity wrote: > Blue Swirl wrote: >> On 8/24/08, Avi Kivity wrote: >> >> >> UUID can be used in all machines, so it would be nice if the interface >> was same. I don't see much benefit in vmport compared to ROM solution. >> >> > > Maybe UUID is generic but the vast majority of things that need to > communicate to qemu will be arch specific. Because it's not an interface we control. VMware automatically upgrades their tool chain and doesn't support backwards compatibility in their tools. They're completely free to change the semantics of the interface. This could really cause confusion within guests. It's one thing to implement vmport based ops when there is existing guest software that we can get working but I think it's not a great idea to write new guest software that's QEMU specific using an interface that we have no control over. Regards, Anthony Liguori