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 09:51:23AM -0500, Anthony Liguori wrote:
>> I can appreciate the desire to keep protocols and formats as an internal 
>> distinction but as a user visible concept, I think your two examples 
>> highlight why exposing protocols as formats make sense.  A user doesn't 
>> necessarily care what's happening under the cover.  I think:
>> 
>> -blockdev format=qcow2,file=image.qcow2,id=blk1
>> 
>> and:
>> 
>> -blockdev protocol=vvfat,file=/tmp/dir,id=blk1
>> 
>> Would cause a bit of confusion.  It's not immediately clear why vvfat is 
>> a protocol and qcow2 isn't.  It's really an implementation detail that 
>> we implement qcow2 on top of a "protocol" called file.
>
> Everything involving vvfat will end up in sheer confusion, and that's
> because vvfat is such a beast.

Yes, vvfat doesn't fit the format/protocol model very well, but that's
because that model sucks :)

vvfat is a block driver.  A block driver requires a number of children.
For vvfat that number is zero.  It can only be a leaf in the block
driver tree.

As with any block driver, you can stack another block driver on top of
it (the parent, in tree parlance).  Also as with any block driver, the
parent might not like the bits it gets from the child.  Yes, stacking
qcow2 on vvfat doesn't work.  Just like stacking qcow2 on your old DOS
partition.

>                                 But it's a rather traditional example
> of a "protocol".  Unlike qcow2 / vmdk / vpc it can not be stacked on
> an arbitrary protocol (file/nbd/http), but rather accessed a directory
> tree.  vvfat then makes up something that looks like a file so upper
> levels can use it like that.  As far as qemu is concerned you can then
> use any format on top of it, but given that it fakes up a fat filesystem
> that format better be raw to make sense.
>
> What about renaming the protocol a transport?  It seems like a lot
> of issues here seem to resolve around naming.
>
> The user basically can specify two things:
>
>  - a transport protocol.  Normally this is just the filesystem
>    interface, but it can also be nbd, http or for really sick people
>    vvfat.  This is a setting which can't be guessed, btw - it needs
>    to be explicitly set in some way, with file used as a reasonable
>    fallback.
>
>  - an image format.  This one interprets the content the transport
>    protocol delivers to us.  This can either be raw for not interpreting
>    it all, or things like qcow2 / vmdk to add more functionality to it.

You describe the special case where format and protocol make some sense:
you have a block driver that can transport bits in arbitrary formats,
and a block driver that interprets bits without caring for transport.

In the general case, we have things like vvfat that make people wonder
whether it's a format or a protocol.  You can't stack it onto a
transport, so it can't be a format!  You can't stack a format on it, so
it can't be a protocol!

[...]