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

[Kevin Wolf <kwolf@redhat.com>]

Am 21.06.2010 15:09, schrieb Anthony Liguori:
> 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.

Not only qcow2, but also raw, qcow, vmdk, vdi, bochs, cow, dmg, ...

In short: Any format needs an underlying protocol. You may not call it
by its name, but that's effectively what you'd implement. And if you
implemented it in each format driver instead of generic code, you'd be
doing a bad implementation.

The more I think about it, the more I believe that the logic of how qemu
handles things is made much clearer if we actually call it by its name
and expose the distinction to the user.

"If there is no protocol specified, qemu will pick one automatically"
vs. "If you specify an image in raw, qcow2, qcow, vmdk, vdi, bochs, cow,
dmg or blkdebug format and you have no backing_dev specified, qemu will
pick one automatically; it won't do so for images in file, host_device,
host_flopy, host_cdrom, nbd, http or vvfat format." It's an easy choice.

> We can still support format probing.  We should drop any support for 
> parameter passing via file name too (with nbd and vfat).

For -blockdev, agreed. We need to retain it with -drive, though.

Kevin