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

[Kevin Wolf]

Am 21.06.2010 17:56, schrieb Markus Armbruster:
> Kevin Wolf <address@hidden> writes:
> 
>> Am 21.06.2010 15:37, schrieb Anthony Liguori:
>>> 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.
>>
>> Probably not. I mean, if you ignore blkdebug for a moment, this is
>> what's implemented today. But it makes a difference between formats and
>> protocols: If you say format=qcow2, you get qcow2 on file. If you say
>> format=file, you get just file with no other protocol because file is
>> already one
> 
> There you go, talking about format and protocol again :)

I'm happy to hear about your theory why there's a difference when
protocols and formats are the same. So...?

>>             (I think what you really should get is an error message, but
>> that's another topic...)
> 
> I disagree.  "file" by itself is a perfectly valid block driver tree.
> 
>>>> 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 hardly need "protocol" to do better than that :)
> 
> First of all, "formats" do not need "protocols".  That's merely a
> special case.  Instead, block drivers need children (tree parlance).
> Backing devices, if you will.

Some block drivers do (formats), others don't (protcols/transports).

> We can and should provide useful defaults and shortcuts.  Instead of "If
> there is no protocol", say "to configure a block driver's child, you can
> do X, Y or Z", where one of the options provides full control, and
> others are shortcuts.  For instance, filename=F could be a shortcut for
> "let QEMU auto-configure a block driver appropriate for file F".
> 
> The "protocol" parlance breaks down when we move away from the simple
> stuff.  For instance, qcow2 needs two children: the block driver
> providing the delta bits (in qcow2 format), and the block driver
> providing the base bits (whose configuration happens to be stored in the
> delta bits).  

Backing files are different. When talking about opening images (which is
what we do here) the main difference is that they can be opened only
after the image itself has been opened. I don't think we should include
them in this discussion.

> All qcow2 wants from them is access to bits.  It doesn't
> care about format vs. protocol at all.  In fact, the driver for the base
> bits is commonly what you'd call a format.  Even the driver for the
> delta bits could be a format.  As long as the bits it provides are valid
> qcow2, the qcow2 driver won't mind.

Right, why should it mind if there's one layer or two layers under it?
Where the difference matters is opening images.

Kevin