Avi Kivity <a...@redhat.com> writes: > On 06/18/2010 03:59 PM, Markus Armbruster wrote: >> The code is pretty confused about format vs. protocol, and so are we. >> Let's try to figure them out. >> >> From cruising altitude, all this format, protocol, stacking business >> doesn't matter. We provide a bunch of arguments, and get an image. >> >> If you look more closely, providing that image involves sub-tasks. One >> is to haul bits. Another one is to translate between bits in different >> formats. >> >> Working hypothesis: >> >> * A protocol hauls image bits. Examples: file, host_device, nbd. >> >> * A format translates image formats. Examples: raw, qcow2. >> >> > > Is there a reason to make the distinction? Is there a reason to > expose the distinction to the user?
After thinking this through by writing a treatise on it, I've come to the conclusion that we're confused about the distinction because it's not a particularly useful one. Evidence: I define the terms "format" and "protocol" in the first section of my treatise. They occur in later sections pretty much only to explain problematic implementation details, or problematic user interface. Making the distinction may still be useful when reasoning about code, e.g. the proper design of block drivers. A possible reason why we currently expose format and protocol at the user interface is to avoid stacking there. Until blkdebug showed up, a drive's "tree" of block drivers had one or two nodes. Another "tree" of one or two for COW's backing image, but those are configured separately. Hardcoding configuration knobs for up to two block drivers avoids having to deal with stacking. We happen to call the two knobs "format" and "protocol". When blkdebug showed up, we shoehorned it into the existing "protocol".
