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: Markus Armbruster
Subject: Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs
Date: Wed, 16 Jun 2010 16:47:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Christoph Hellwig <address@hidden> writes:

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

Agree.

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

So we still don't agree on what a protocol is?!?

Talking about concrete command line syntax makes no sense at all before
we agree on the abstract syntax, i.e. the information we want to convey.
Please go right back to the head of the thread, and review the QMP
command docs.  The QMP JSON is a straightforward concrete syntax for the
abstract syntax.



reply via email to

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