qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Glauber Costa" <glommer@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds
Date: Thu, 11 Sep 2008 08:44:41 -0300	[thread overview]
Message-ID: <5d6222a80809110444t75ec91fau15d8aaaaa7ea4173@mail.gmail.com> (raw)
In-Reply-To: <20080911081858.GA12261@shareable.org>

On Thu, Sep 11, 2008 at 5:18 AM, Jamie Lokier <jamie@shareable.org> 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."

  reply	other threads:[~2008-09-11 11:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-11  0:19 [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds Marc Bevand
2008-09-11  0:30 ` Anthony Liguori
2008-09-11  1:19   ` Marc Bevand
2008-09-11  1:40     ` Glauber Costa
2008-09-11  3:34       ` Marc Bevand
2008-09-11  8:18         ` Jamie Lokier
2008-09-11 11:44           ` Glauber Costa [this message]
2008-09-11 11:56             ` Jamie Lokier
2008-09-11 13:58               ` Paul Brook
2008-09-11 14:11                 ` Avi Kivity
2008-09-11 15:16                 ` Ian Kirk
2008-09-11 15:55                   ` Paul Brook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5d6222a80809110444t75ec91fau15d8aaaaa7ea4173@mail.gmail.com \
    --to=glommer@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).