Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack

[Markus Armbruster]

Christoph Hellwig <address@hidden> writes:

> On Mon, Jun 21, 2010 at 10:37:37AM -0500, Anthony Liguori wrote:
[...]
>> [2] -blockdev format=vvfat,file=/path/to/directory,id=blk1
>> 
>> 
>> It's not clear to me why [2] should be transport=vvfat.  vvfat really 
>> isn't a transport.
>
> Well, it's a wart if you want to be exact.  But in the above model
> it's a clearly a transport.  It does not take an arbitrary BlockDriver
> on the layer below it but implements it's own I/O methods not using the
> qemu block layer - it maps from an image file the filesystem namespace.
> Similar to file connects to a file on the local system and nbd/http
> connects an image on a remote system.
>
>> What about things like blkdebug and if we had 
>> something like a ramdisk?
>
> A ramdisk again is a transport into a file that's purely in-memory.
> You can trivially run any format we have ontop of it.
>
> blkdebug in it's current form is a trivial image format, just like raw
> in the above terminology.  It takes an arbitrary qemu BlockDriver as
> input and then stacks on top.

blkdebug could be viewed as transport just as well: it transports bits
in arbitrary formats.  In your own words: "You can trivially run any
format we have ontop of it."

> Think of a protocol/transport as the thing that implements the lowest
> layer of the qemu block I/O stack which then maps to native I/O methods.

We're still discussing whether a certain block driver is a "format" or a
"protocol".  And we're still disagreeing.

I don't think the format vs. protocol distinction is useful.

The job at hand is to configure a tree of block drivers.  In QMP, HMP,
command line and config file.

For QMP, why don't we do just that?  Trees are perfectly natural there,
and arbitrarily dividing trees into format and protocol parts only
complicates things.

For the rest, let's rely on sensible defaults and perhaps a few shortcut
forms for common cases.