Am 21.06.2010 18:21, schrieb Markus Armbruster: > Christoph Hellwig <h...@lst.de> 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 :)
What's the different between vvfat and accessing a FAT image via nbd (except that vvfat is broken)? It's clearly a protocol/transport, as Christoph already said. > 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. No, that's not a special case. It's the only case there is. > 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! Sure you can stack formats on it. raw and blkdebug are the ones that will be happy with the data that vvfat provides. Kevin