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

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/21/2010 08:30 AM, Kevin Wolf wrote:
> 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.
>    

Sure.  I don't think it would be all that difficult to implement in 
common code.

> 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.
>    

Are you basically saying:

[1] -blockdev format=qcow2,protocol=file,file=foo.img,id=blk1

Because what I was suggesting is that we don't allow protocol=XX here.  
We would try to guess the protocol from foo.img.  If a user wishes to 
override this, they should do the full syntax of:

[2] -blockdev protocol=host_dev,file=/dev/sda,id=base \
-blockdev format=qcow2,backing_dev=base,id=blk1

But we're also suggesting s/protocol/format/ because the distinction 
doesn't seem to be important unless you try to support syntax [1] and 
you need a mechanism to specify the leaf format (which you're calling a 
protocol).

Regards,

Anthony Liguori

>> 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
>