From: Kevin Wolf <kwolf@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Christoph Hellwig <chellwig@redhat.com>,
qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>,
Avi Kivity <avi@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs
Date: Fri, 04 Jun 2010 16:32:28 +0200 [thread overview]
Message-ID: <4C090E7C.1080009@redhat.com> (raw)
In-Reply-To: <m3aarayjbn.fsf@blackfin.pond.sub.org>
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
next prev parent reply other threads:[~2010-06-04 14:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-28 18:21 [Qemu-devel] RFC: blockdev_add & friends, brief rationale, QMP docs Markus Armbruster
2010-05-28 19:13 ` [Qemu-devel] " Kevin Wolf
2010-05-28 19:17 ` Anthony Liguori
2010-05-28 19:24 ` Luiz Capitulino
2010-05-30 9:11 ` Avi Kivity
2010-05-31 11:05 ` Markus Armbruster
2010-05-31 13:48 ` Luiz Capitulino
2010-05-31 14:04 ` Kevin Wolf
2010-05-30 9:09 ` Avi Kivity
2010-05-31 10:54 ` Markus Armbruster
2010-05-31 11:23 ` Avi Kivity
2010-05-31 11:50 ` Markus Armbruster
2010-06-04 14:16 ` Markus Armbruster
2010-06-04 14:32 ` Kevin Wolf [this message]
2010-06-04 15:53 ` Markus Armbruster
2010-06-04 16:20 ` Kevin Wolf
2010-06-06 8:23 ` Avi Kivity
2010-06-08 9:41 ` 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=4C090E7C.1080009@redhat.com \
--to=kwolf@redhat.com \
--cc=armbru@redhat.com \
--cc=avi@redhat.com \
--cc=chellwig@redhat.com \
--cc=kraxel@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).