Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Glauber Costa]

On Thu, Sep 11, 2008 at 5:18 AM, Jamie Lokier <address@hidden> 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.
So yes, this is something the user would should expect. Maybe we don't
need to be so strict and don't
show the minor version in updates. But we can't guarantee that future
qemu updates won't change the
way the O.S. views hardware significantly.

>
>> 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
>
>
>



-- 
Glauber Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."