Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/16/2010 08:57 AM, Kevin Wolf wrote:
> Am 16.06.2010 15:41, schrieb Anthony Liguori:
>    
>> On 06/16/2010 07:41 AM, Markus Armbruster wrote:
>>      
>>> Kevin Wolf<kwolf@redhat.com>   writes:
>>>        
>>>> But it's painful to type for the user. After all -blockdev on the
>>>> command line is for the user, as tools should use QMP. Also note that
>>>> this syntax mixes format and protocol options on one line which I
>>>> consider confusing at best.
>>>>
>>>> As I told Markus already in private before he posted this, I prefer the
>>>> bracket solution for its clarity and simplicity, even though it comes at
>>>> the cost of having additional characters that need to be escaped.
>>>>
>>>>          
>>> I dont't think 1. is less painful than 3.  Let's compare the two:
>>>
>>> * Single protocol: identical with suitable syntactical sugar, namely
>>>
>>>         -blockdev id=blk1,file=fedora.img
>>>
>>>        
>> First, let me say that -blockdev is not something that I believe is
>> targeted at users.  It's incredible unfair for us to expect a user to type:
>>
>> -blockdev id=blk1,file=fedora.img -device ide-drive,drive=blk1,bus=0,unit=0
>>
>> Instead of:
>>
>> -hda fedora.img
>>      
> Sure thing, as long as -hda provides all the options. I usually start
> off with -hda, but after a while I need to set some option and switch to
> -drive. This is what most users are using today.
>
> If we're not going to extend -drive to cover all features, then users
> will (have to) start using -blockdev.
>
>    
>> I had to look up the device syntax just to write that.  There's no way
>> users are going to do this.  We should drop any notion of syntactical
>> sugar IMHO.  -blockdev is for management tools, scripts, and as an
>> infrastructure for config files.
>>      
> In that case, let's go for the JSON version.

We need separate options to map to a configuration file.  We already 
represent trees of information in the configuration files and there's an 
established way of doing this (naming nodes with 'id' and then 
referencing them as a parent).

>   But it requires that
> everything that -blockdev provides is accessible with -drive, too (or
> that we're okay with users hating us).
>    

I'm happy for -drive to die.  I think we should support -hda and 
-blockdev.  -blockdev should be optimized for config files, not single 
argument input.  IOW:

[blockdev "blk2"]
  format = "raw"
  file = "/path/to/base.img"
  cache = "writeback"

[blockdev "blk1"]
   format = "qcow2"
   file = "/path/to/leaf.img"
   cache="off"
   backing_dev = "blk2"

[device "disk1"]
   driver = "ide-drive"
   blockdev = "blk1"
   bus = "0"
   unit = "0"

Or:

qemu -blockdev id=blk2,format=raw,file=/path/to/base.img,cache=writeback \
           -blockdev 
id=blk1,format=qcow2,file=/path/to/leaf.img,backing_dev=blk2 \
           -device ide-disk,blockdev=blk1,bus=0,unit=0

Or:

qemu -hda /path/to/leaf.img

And if a user really feels they need to modify the defaults, they can do:

qemu -hda /path/to/leaf.img -writeconfig myconf.cfg

And edit from there.

>> But honestly, I'm thoroughly confused about the distinction between
>> protocol and format.  I had thought that protocols were a type of format
>> and I'm not sure why we're making a distinction.
>>      
> Technically, they are mostly the same. Logically, they are not. You have
> one image format driver (raw, qcow2, ...) that accesses its image data
> through one or more stacked protocols (file, host_device, nbd, http, ...).
>
> In the past we've had quite some trouble because there was no clear
> distinction. raw and file was the same. If you had an image on a block
> device, you were asking for trouble.
>    

As Christoph mentions, we really don't have stacked protocols and I'm 
not sure they make sense.

>>>     I sure prefer the latter.  The brackets look like noise.  You need to
>>>     understand protocol stacking for them to make any sense.
>>>
>>>     Regarding confusion caused by mixing format and protocol options: yes,
>>>     the brackets force you to distinguish between protocol options and
>>>     other options.  But I doubt that'll reduce confusion here.  Either you
>>>     understand protocols.  Then I doubt you need brackets to unconfuse
>>>     you.  Or you don't understand protocols.  Then whether to put an
>>>     option inside or outside the brackets is voodoo.
>>>
>>>        
>> If the above is necessary just to create a raw image, then we're doing
>> something wrong in the block layer.  If should be possible to just say:
>>
>> -blockdev id=blk1,format=raw,file=fedora.img
>>      
> I think we all agree on this (although it contradicts what you said
> above, because file is a property of the protocol). The question is how
> to specify protocols explicitly.
>    

I think raw doesn't make very much sense then.  What's the point of it 
if it's just a thin wrapper around a protocol?

Regards,

Anthony Liguori

> Kevin
>