From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36126 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOqff-0001xv-TO for qemu-devel@nongnu.org; Wed, 16 Jun 2010 07:20:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOqfe-0000nI-V1 for qemu-devel@nongnu.org; Wed, 16 Jun 2010 07:20:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1518) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOqfe-0000nA-Lj for qemu-devel@nongnu.org; Wed, 16 Jun 2010 07:20:38 -0400 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5GBKbhH005521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 Jun 2010 07:20:38 -0400 Message-ID: <4C18B375.4050900@redhat.com> Date: Wed, 16 Jun 2010 13:20:21 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <4C1783CC.7070307@redhat.com> In-Reply-To: <4C1783CC.7070307@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Christoph Hellwig , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino , Gerd Hoffmann 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. Kevin