From: Christoph Hellwig <hch@lst.de>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Christoph Hellwig <chellwig@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>,
Avi Kivity <avi@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs
Date: Wed, 16 Jun 2010 16:24:25 +0200 [thread overview]
Message-ID: <20100616142425.GA17432@lst.de> (raw)
In-Reply-To: <4C18D85A.1050208@redhat.com>
On Wed, Jun 16, 2010 at 03:57:46PM +0200, Kevin Wolf wrote:
> Sure thing, as long as -hda provides all the options. I usually start
> off with -hda, but after a while I need to set some option and switch to
> -drive. This is what most users are using today.
I've never even bothered using -hda - it's not anywhere near useful
for usable setup (cache=none, virtio & co).
> If we're not going to extend -drive to cover all features, then users
> will (have to) start using -blockdev.
-drive is such a mess that we need to fully replace it.
> Technically, they are mostly the same. Logically, they are not. You have
> one image format driver (raw, qcow2, ...) that accesses its image data
> through one or more stacked protocols (file, host_device, nbd, http, ...).
That's where it gets really confusing. To my naive sense everything
that takes fileish input below is an image format. So to me stacking
image formats makes sense, stacking protocols as the fundamental way
to access data (file/http/nbd) doesn't.
The only stacking protocol right now is blkdebug, and that would fit
much better as a stacking image format, which could use ->bdrv_open
instead of ->bdrv_file_open, etc. The only thing we'd require for that
is allowing to pass options to image formats.
next prev parent reply other threads:[~2010-06-16 14:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-10 17:45 [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs Markus Armbruster
2010-06-15 9:04 ` Avi Kivity
2010-06-15 12:23 ` Markus Armbruster
2010-06-15 12:43 ` Avi Kivity
2010-06-15 13:27 ` Markus Armbruster
2010-06-15 13:40 ` Avi Kivity
2010-06-15 14:54 ` Markus Armbruster
2010-06-16 9:50 ` Avi Kivity
2010-06-16 11:02 ` Markus Armbruster
2010-06-16 11:06 ` Avi Kivity
2010-06-15 13:44 ` [Qemu-devel] " Avi Kivity
2010-06-15 14:39 ` Gerd Hoffmann
2010-06-16 11:20 ` Kevin Wolf
2010-06-16 12:41 ` Markus Armbruster
2010-06-16 13:41 ` Anthony Liguori
2010-06-16 13:57 ` Kevin Wolf
2010-06-16 14:24 ` Christoph Hellwig [this message]
2010-06-16 14:47 ` Markus Armbruster
2010-06-16 18:07 ` Anthony Liguori
2010-06-17 8:20 ` Kevin Wolf
2010-06-17 13:01 ` Anthony Liguori
2010-06-17 14:15 ` Kevin Wolf
2010-06-18 8:20 ` Markus Armbruster
2010-06-18 9:36 ` Kevin Wolf
2010-06-18 7:06 ` Markus Armbruster
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=20100616142425.GA17432@lst.de \
--to=hch@lst.de \
--cc=armbru@redhat.com \
--cc=avi@redhat.com \
--cc=chellwig@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=lcapitulino@redhat.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).