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

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/22/2010 07:57 AM, Kevin Wolf wrote:
>>> 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?
>    

Yes.  I think once you do an explicit option, you have to be very careful.

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

I understand the concern but I think one of the big problems with -drive 
and bdrv_open today is they are far too magical.  We shouldn't make the 
same mistake again.

We ought to keep in my the 80/20 rule.  In this case, I'm fairly certain 
that it's closer to 99% of users are only doing 1% of what is actually 
possible and generally that's going to either be -hda foo.img or 
-blockdev file=foo.img,option=value.

Regards,

Anthony Liguori

> Kevin
>