Kevin Wolf <kw...@redhat.com> writes: > Am 21.06.2010 18:21, schrieb Markus Armbruster: >> Christoph Hellwig <h...@lst.de> writes: >> [...] >>> 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.
You can stack raw and blkdebug on *anything*. And that includes qcow2. Does that make qcow2 a protocol? Are we running in circles yet? :) I've come the conclusion that distinguishing between format and protocol doesn't help. It only breeds confusion (and e-mail, lots of e-mail). I've rethought blockdev_add, and I think I can do quite well without format and protocol. Let me try that in practice. I'll post revised docs & code when I have them.
