qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QM


From: Christoph Hellwig
Subject: Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs
Date: Wed, 16 Jun 2010 16:24:25 +0200
User-agent: Mutt/1.3.28i

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]