[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs
From: |
Kevin Wolf |
Subject: |
[Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs |
Date: |
Fri, 04 Jun 2010 16:32:28 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 |
Am 04.06.2010 16:16, schrieb Markus Armbruster:
> Discussion with Christoph and Kevin uncovered yet another issue:
> protocols. I find it pretty confusing, but let me try to describe it
> anyway; Christoph and Kevin, please correct my errors.
>
> A host block device has a format. A format has a name.
>
> Below the format, it has a stack of protocols. A protocol has a name
> (with one exception), and may have protocol-specific arguments.
>
> The most basic (and most commonly used) protocol is for accessing a
> file. Its argument is a file name. It doesn't have a name. Which
> makes for ugly prose, so I'll call it "file".
It does have a name, and surprisingly it's called "file" indeed (defined
at block/raw-posix.c:744 for Linux).
> Stacking protocols is somewhat exotic. Think of stacking blkdebug on
> top of another protocol, say nbd.
Considering that file is a protocol as well as nbd, it's any blkdebug
use that uses protocol stacking and therefore not that exotic - even
though not the most common case, of course.
> Our abstraction for formats is struct BlockDriver.
>
> Our abstraction for protocols is also struct BlockDriver. Except for
> the special protocol "file", but that's detail.
See above, file isn't really special.
>
> Examples:
>
> -drive file=foo.qcow2,format=qcow2
>
> Format "qcow2", protocol "file" with argument filename "foo.img"
Actually the protocol is guessed here. For this, not all protocols are
considered, it's only between file/host_device/host_cdrom/host_floppy
(these are the protocols implementing bdrv_probe_device, and file as the
default if no other protocol feels responsible)
> -drive file=nbd:unix:/tmp/my_socket,format=raw
>
> Format "raw", protocol "nbd" with arguments domain "unix", filename
> "/tmp/my_socket"
>
> -drive blkdebug:/tmp/blkdebug.cfg:fat:floppy:rw:/tmp/dir
>
> Format not specified (system guesses one), protocol "blkdebug" with
> argument filename "/tmp/blkdebug.cfg" stacked onto protocol "fat" with
> arguments floppy true, dirname "/tmp/dir"
These look right to me.
>
> You see that -drive has a separate option for format, but has protocols
> encoded in option file, in their own mini-language. Doesn't work for
> arbitrary filenames. Besides, mini-languages to encode options in
> strings are quite inappropriate for QMP.
>
> So we need something cleaner for QMP. Here's a sketch. Instead of
>
> - "file": the disk image file to use (json-string, optional)
> - "format": disk format (json-string, optional)
> - Possible values: "raw", "qcow2", ...
>
> have
>
> - "format": disk format (json-string, optional)
> - Possible values: "raw", "qcow2", ...
> - "protocol": json-array of json-object
> Each element object has a member "name"
> - Possible values: "file", "nbd", ...
> Additional members depend on the value of "name".
> For "name" = "file":
> - "file": file name (json-string)
> For "name" = "nbd":
> - "domain": address family (json-string, optional)
> - Possible values: "inet" (default), "unix"
> - "file": file name (json-string), only with "domain" = "unix"
> - "host": host name (json-string), only with "domain" = "inet"
> - "port": port (json-int), only with "domain" = "inet"
> ...
>
> You get the idea.
>
> Comments?
Makes sense.
So blkdebug would define a field "protocol" (json-object) that it uses
to initialize the underlying protocol and we would get the stacking this
way?
Kevin