From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kdkmn-0005nd-LC for qemu-devel@nongnu.org; Thu, 11 Sep 2008 07:56:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kdkmm-0005mG-4c for qemu-devel@nongnu.org; Thu, 11 Sep 2008 07:56:33 -0400 Received: from [199.232.76.173] (port=53822 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kdkml-0005m1-Sv for qemu-devel@nongnu.org; Thu, 11 Sep 2008 07:56:31 -0400 Received: from mail2.shareable.org ([80.68.89.115]:46119) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kdkml-0007oj-M8 for qemu-devel@nongnu.org; Thu, 11 Sep 2008 07:56:31 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Kdkmk-0004I6-5D for qemu-devel@nongnu.org; Thu, 11 Sep 2008 12:56:30 +0100 Date: Thu, 11 Sep 2008 12:56:30 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds Message-ID: <20080911115629.GA16427@shareable.org> References: <48C8669D.2000103@codemonkey.ws> <5d6222a80809101840h61cd60c9y767b87333a5f5a00@mail.gmail.com> <20080911081858.GA12261@shareable.org> <5d6222a80809110444t75ec91fau15d8aaaaa7ea4173@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d6222a80809110444t75ec91fau15d8aaaaa7ea4173@mail.gmail.com> 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 Glauber Costa wrote: > On Thu, Sep 11, 2008 at 5:18 AM, Jamie Lokier wrote: > > 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 :-) > > My point is that in this case, you _are_ changing hardware. QEMU is a > piece of hardware anyway. If that is a hardware change, can we please have an option _not_ to change the hardware when upgrading QEMU ;-) > But we can't guarantee that future qemu updates won't change the way > the O.S. views hardware significantly. We should. If upgrading QEMU changes the emulated hardware significantly, it'll break some guests - not just Windows, but sane guests with drivers not expecting the hardware to be suddenly different :-) Significant changes should be accompanied by options, in the same way that, say, you can select among different NICs, and ought to be able to select among PIIX3 and PIIX4 etc. Bug fixes and performance improvements are fine. -- Jamie