On 06/21/2010 03:19 AM, Kevin Wolf wrote:
Am 20.06.2010 12:51, schrieb Avi Kivity:
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?
There are good reasons to make that distinction internally. There's no
need to expose it to the user - the question is if it helps or not.
If we drop the distinction, then I think the remaining issue is how to
expose the stacking to a user.
Right now, we could have a syntax like:
-blockdev format=file,file=image.qcow2,id=base \
-blockdev format=qcow2,backing_dev=base,id=blk1
backing_dev is a sucky name, but hopefully the point is clear. I think
the following would be a better user syntax:
-blockdev format=qcow2,file=image.qcow2,id=blk1
I think the easiest way to support this is to make qcow2 take a file
parameter and have it open the file with default options. For users
that need anything more sophisticated a user has to use the former syntax.
We can still support format probing. We should drop any support for
parameter passing via file name too (with nbd and vfat).
Regards,
Anthony Liguori
Historically, format and protocol are defined like this (so in fact they
are user-visible currently):
* A format is what you specify as file=...
* A protocol is what is encoded in the file name
And I think as long as you have exactly one format and one protocol,
it's easier to understand than a chain of block drivers. But that's
really just about how to expose it.
Kevin
