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

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/22/2010 03:10 AM, Kevin Wolf wrote:
> Am 21.06.2010 17:34, schrieb Anthony Liguori:
>    
>> On 06/21/2010 09:01 AM, Kevin Wolf wrote:
>>      
>>> No, what I'm saying is that even in your model
>>>
>>>     -blockdev format=qcow2,file=image.qcow2,id=blk1
>>>
>>> becomes qcow2 ->   file automatically, whereas
>>>
>>>     -blockdev format=vvfat,file=/tmp/dir/,id=blk1
>>>
>>> doesn't become vvfat ->   file, but stays just vvfat.
>>>
>>>        
>> I should say, that -blockdev format= vs. -blockdev transport= is
>> definitely at a place where I don't care that much.
>>
>> The things that I think are most important are:
>>
>> 1) That we have structured options that map well to config file without
>> trickery to do nesting
>> 2) That we don't automagically pass options through from the first layer
>> down to subsequent layers
>>      
> Does this mean that you need to specify the protocol explicitly for any
> non-trivial case? So if you want to use just default for everything you
> can use
>
>    -blockdev id=foo,format=qcow2,file=foo.qcow2
>    

Yes.  I think we should explicitly support an option like file.

> and it will be turned into something sensible automagically (namely
> adding a file blockdev underneath and passing the file parameter to that
> one), but if you want to change an option, you need to specify both?
>
>    -blockdev id=foo,format=qcow2,parent=foo_file
>    -blockdev id=foo_file,format=file,file=foo.qcow2,cache=off
>
> What about read-only?

Good question.  If a user specifies file, I think the (or generic block 
layer) should have wide latitude to decide how to creating that backing 
format which could include propagating options that it thinks are 
reasonable (like readonly).

My concern is seeing something like:

-blockdev id=foo,format=qcow2,file=blah.img,funkyopt=value

or:

-blockdev id=foo,format=qcow2,protocol=[file=blah.img,funkyopt=value]

I think the later syntax is overwhelming.  If the semantics of the 
former syntax is "passthrough any options we don't understand at this 
layer", I'm afraid it gets too confusing about which level actually 
processed the option (and it certainly doesn't deal with propagation).

Regards,

Anthony Liguori

>   Is it something that must be specified for each
> single node in the chain to actually get the right semantics?
>
> Kevin
>