All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Christoph Hellwig <hch@lst.de>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/4] block: add block topology options
Date: Fri, 5 Feb 2010 16:16:20 +0000	[thread overview]
Message-ID: <20100205161620.GB18601@shareable.org> (raw)
In-Reply-To: <20100205130956.GA17475@lst.de>

Christoph Hellwig wrote:
> On Wed, Feb 03, 2010 at 01:00:47PM -0600, Anthony Liguori wrote:
> > But I don't think this is the wrong place to do it.  The 
> > BlockDriverState reflects that backing device, not the emulated device 
> > itself.  In this case, you're trying to set a property of the emulated 
> > device.
> 
> I think that's very borderline.  While the emulated device exposes these
> properties, they are in fact a property of the backing storage, the
> right sector and min/max I/O sizes are determined by the backing storage
> device.
> 
> > I think these need to be qdev properties of the respective devices.  
> > From a UI perspective, you can still expose -drive options for the end 
> > user to consume, but this data should be associated with the devices 
> > themselves.
> 
> In addition to not really beeing more logical this would be a lot more
> effort.  We'd need to add properties to all the device, which means
> including dealing with the n+1 ide variants, the virtio-pci proxy, etc.
> 
> If you believe it really needs to be in the qdev properties I'll
> implement it, but I suspect the current version is a better idea.

If you move your VM to a new system with different backing devices,
sometimes you want to be sure there is no guest-visible change.  Or
even if you just replace a drive - you might prefer confidence that
the guest sees no change.

Even if you just convert between qcow2 and a raw block device, or the
other way, you'll sometimes want to be sure it's not guest-visible.

-- Jamie

  reply	other threads:[~2010-02-05 16:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-29 19:04 [Qemu-devel] [PATCH 1/4] virtio-blk: revert serial number support Christoph Hellwig
2010-01-29 19:04 ` [Qemu-devel] [PATCH 2/4] block: add block topology options Christoph Hellwig
2010-02-03 19:00   ` Anthony Liguori
2010-02-05 13:09     ` Christoph Hellwig
2010-02-05 16:16       ` Jamie Lokier [this message]
2010-02-05 16:22         ` Christoph Hellwig
2010-02-05 17:16           ` Jamie Lokier
2010-02-05 17:33       ` Anthony Liguori
2010-02-09 15:26         ` Markus Armbruster
2010-01-29 19:05 ` [Qemu-devel] [PATCH 3/5] scsi: add topology support Christoph Hellwig
2010-01-29 19:05 ` [Qemu-devel] [PATCH 4/5] ide: " Christoph Hellwig
2010-01-29 19:05 ` [Qemu-devel] [PATCH 5/5] virtio-blk: " Christoph Hellwig
2010-02-01  9:09   ` [Qemu-devel] [PATCH v2 " Christoph Hellwig

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=20100205161620.GB18601@shareable.org \
    --to=jamie@shareable.org \
    --cc=hch@lst.de \
    --cc=martin.petersen@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.