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

[Kevin Wolf]

Am 22.06.2010 14:39, schrieb Anthony Liguori:
> 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.

Makes sense. I don't really like adding some special magic for file, but
I do see that it's a requirement to make at least the simplest case easy
- and this was about the only clear result of my discussion with Markus
before he posted his proposal.

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

Right, if we get to use a default value, we can propagate things that
the generic block layer knows. However, as soon as someone specifies a
protocol explicitly, he'll need to add readonly=on to each -blockdev in
the chain?

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

The former involves definitely too much magic for assigning the options
to the right blockdev. The latter would be more comprehensible, but
isn't really nice either.

On the other hand, funkyopt might be something as common as cache, and
I'd hate to require specifying the protocol explicitly in a second
-blockdev referenced by another ID when you just want to change the
cache option.

Kevin