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.
