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

[Anthony Liguori]

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<address@hidden>   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
>