qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: block: format vs. protocol, and how they stack


From: Anthony Liguori
Subject: [Qemu-devel] Re: block: format vs. protocol, and how they stack
Date: Mon, 21 Jun 2010 08:09:22 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]