qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs
Date: Wed, 16 Jun 2010 08:41:23 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4

On 06/16/2010 07:41 AM, Markus Armbruster wrote:
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

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

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.

   Unsugared it's

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

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

Specifying nesting in a single option is a bad idea.  It should be:

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

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.

   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

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]