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

[Markus Armbruster]

Kevin Wolf <address@hidden> writes:

> Am 15.06.2010 15:44, schrieb Avi Kivity:
>> On 06/10/2010 08:45 PM, Markus Armbruster wrote:
>>>
>>>
>>>     * Our config file format is in INI syntax.  QemuOpts correspond to
>>>       INI sections.  Sections can't be nested, so recursive QemuOpts
>>>       don't translate.
>>>    
>> 
>> git (and probably others) use
>> 
>> [a "b"]
>>      c = d
>> 
>> for
>> 
>>     a.b.c=d
>> 
>>>     Examples:
>>>
>>>     * Single protocol:
>>>
>>>       -blockdev id=blk1,format=raw,protocol=[file,file=fedora.img]
>>>
>>>       Requires suitable syntactic sugar to get the simple form (*).
>>>
>>>     * blkdebug
>>>
>>>       -blockdev id=blk2,format=qcow2,\
>>>       protocol=[blkdebug,config=test.blkdebug,\
>>>       protocol=[file,file=test.qcow2]]
>>>
>>>     * Avi's mirror:
>>>
>>>       -blockdev id=blk3,format=raw,\
>>>       protocol=[mirror,\
>>>       [file,file=local.img],\
>>>       [nbd,domain=unix,sockert=nbd-sock]]
>>>
>>> 2. We already have a syntax to specify trees, namely JSON, so use it
>>>
>>>     If -blockdev's argument starts with '{', it's a JSON object suitable
>>>     as argument of blockdev_add in QMP.
>>>
>>>     We still provide ordinary QemuOpts syntax for the cases that can be
>>>     expressed with it, i.e. single protocol.
>>>
>>>     I figure we'd want syntactic sugar for blkdebug, to permit its use
>>>     from the command line without having to resort to JSON.
>>>    
>> 
>> Might be nice as a general extension to QemuOpts.
>
> I agree.
>
>> 
>>> 3. Stack protocols through named references
>>>
>>>     The first protocol is "inlined" into -blockdev.  Any further
>>>     protocols need to be referenced by name.
>>>
>>>     Best explained by example:
>>>
>>>     * Single protocol:
>>>
>>>       -blockdev id=blk1,format=raw,protocol=file,file=fedora.img
>>>
>>>       To get the simple form (*), make protocol optional with a suitable
>>>       default.
>>>
>>>     * blkdebug
>>>
>>>       -blockdev 
>>> id=blk2,format=qcow2,protocol=blkdebug,config=test.blkdebug,\
>>>       base=blk2-base
>>>       -blockproto id=blk2-base,protocol=file,file=test.qcow2
>>>
>>>     * Avi's mirror:
>>>
>>>       -blockdev id=blk3,format=raw,protocol=mirror,\
>>>       base=blk3-base1,base=blk3=base2
>>>       -blockproto id=blk3-base1,protocol=file,file=local.img
>>>       -blockproto id=blk3-base2,protocol=nbd,domain=unix,sockert=nbd-sock
>>>
>>>     Anything but a single protocol becomes pretty verbose.  Syntactic
>>>     sugar for the blkdebug case would be possible; not sure it's worth
>>>     it.
>>>
>>>     No QemuOpts syntax changes.  INI can handle this just fine.
>>>
>>>    
>> 
>> Looks like the least painful option as no new infrastructure is needed.  
>> I'd go with this.
>
> 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

  Unsugared it's

      -blockdev id=blk1,format=raw,protocol=[file,file=fedora.img]
  vs.

      -blockdev id=blk1,format=raw,protocol=file,file=fedora.img

  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.

* blkdebug:

      -blockdev id=blk2,format=qcow2,\
      protocol=[blkdebug,config=test.blkdebug,\
      protocol=[file,file=test.qcow2]]

  vs.

      -blockdev id=blk2,format=qcow2,protocol=blkdebug,config=test.blkdebug,\
      base=blk2-base
      -blockproto id=blk2-base,protocol=file,file=test.qcow2

  Both look equally painfull to me.  It's slightly shorter with
  brackets, but I can't recognize "clarity and simplicity" there.

  To really reduce pain, we'd have to invent special-purpose syntactic
  sugar in either case.

* Avi's mirror:

      -blockdev id=blk3,format=raw,\
      protocol=[mirror,\
      [file,file=local.img],\
      [nbd,domain=unix,sockert=nbd-sock]]

  vs.

      -blockdev id=blk3,format=raw,protocol=mirror,\
      base=blk3-base1,base=blk3=base2
      -blockproto id=blk3-base1,protocol=file,file=local.img
      -blockproto id=blk3-base2,protocol=nbd,domain=unix,sockert=nbd-sock

  Same as for blkdebug.

Both with brackets and with -blockproto the protocol is clearly
separated.  Only the topmost protocol isn't with -blockproto.  I keep
that in -blockdev merely for brevity.  It could live in its own
-blockproto.

Brackets cause some ugly complications, both in the code and in the user
interface, as detailed in my original message.  We need some pretty
convincing advantages to justify those complications.  I can't see them.