From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KdhOI-0004OL-2k for qemu-devel@nongnu.org; Thu, 11 Sep 2008 04:19:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KdhOH-0004Nt-6W for qemu-devel@nongnu.org; Thu, 11 Sep 2008 04:19:01 -0400 Received: from [199.232.76.173] (port=55821 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdhOG-0004Nq-85 for qemu-devel@nongnu.org; Thu, 11 Sep 2008 04:19:00 -0400 Received: from mail2.shareable.org ([80.68.89.115]:45451) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KdhOF-0003iZ-Uq for qemu-devel@nongnu.org; Thu, 11 Sep 2008 04:19:00 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1KdhOE-0003Dd-GT for qemu-devel@nongnu.org; Thu, 11 Sep 2008 09:18:58 +0100 Date: Thu, 11 Sep 2008 09:18:58 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds Message-ID: <20080911081858.GA12261@shareable.org> References: <48C8669D.2000103@codemonkey.ws> <5d6222a80809101840h61cd60c9y767b87333a5f5a00@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Marc Bevand wrote: > Consider this scenario: I change the MAC and the host at some point; > no reactivation required. 10 months later I simply upgrade QEMU from > 0.9.0 to 0.9.1 and change nothing else; reactivation is required. This > is not something an enduser would expect. I agree. (Also I agree with Glauber that the OS is sucky to care, but it does and it's a notable use of QEMU to let you run Windows as a guest so you can run Linux as a host :-) > Another way to see it is that I was in control of the MAC and host > change, but not of the IDENTIFY replies. An enduser should always be > in control of the "hardware changes" he makes to a guest. I agree. If it's something which changes by default, then it should be settable to a fixed value by the user somehow. (Same goes for other identifications the guest might see - I see that Microsoft Virtual PC lets you specify a few of them in its config file.) > Also, I believe (but am not sure) that if I had installed Windows on > QEMU version A and upgraded to version B to C to D, then Windows would > require reactivation after the upgrade to D because it would be seen > as the 3rd "hardware change". I don't think Windows counts these as multiple changes, but I'm not sure. -- Jamie