From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58341 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOssA-00072U-BZ for qemu-devel@nongnu.org; Wed, 16 Jun 2010 09:41:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOss8-0000FG-RH for qemu-devel@nongnu.org; Wed, 16 Jun 2010 09:41:42 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:37890) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOss8-0000Ex-KD for qemu-devel@nongnu.org; Wed, 16 Jun 2010 09:41:40 -0400 Received: by iwn10 with SMTP id 10so6525212iwn.4 for ; Wed, 16 Jun 2010 06:41:39 -0700 (PDT) Message-ID: <4C18D483.4080200@codemonkey.ws> Date: Wed, 16 Jun 2010 08:41:23 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs References: <4C1783CC.7070307@redhat.com> <4C18B375.4050900@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Christoph Hellwig , qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity , Gerd Hoffmann On 06/16/2010 07:41 AM, Markus Armbruster wrote: > Kevin Wolf 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