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

[Christoph Hellwig <hch@lst.de>]

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

Keeping these separate makes a lot of sense to me, even with my user
hat on.  And as lon as we don't require the transport protocol but fall
back to file it's even more understandable for the users, as he simply
doesn't have to care about it for the 99% case.  Now for the image
format specifying it usually is a good thing as the autodetecting could
easily get into trouble when the guest creates say a full-device qcow2
image in a device that's an image file on the host.