From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Why76-0002tg-HU for qemu-devel@nongnu.org; Wed, 07 May 2014 05:26:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Why6y-0000nh-3P for qemu-devel@nongnu.org; Wed, 07 May 2014 05:26:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Why6x-0000nX-JR for qemu-devel@nongnu.org; Wed, 07 May 2014 05:25:59 -0400 Date: Wed, 7 May 2014 10:39:58 +0200 From: Kevin Wolf Message-ID: <20140507083958.GD4045@noname.str.redhat.com> References: <1399404625-6093-1-git-send-email-mreitz@redhat.com> <1399404625-6093-4-git-send-email-mreitz@redhat.com> <53693EC1.3080303@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <53693EC1.3080303@redhat.com> Subject: Re: [Qemu-devel] [PATCH 3/4] block: Allow JSON filenames List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 06.05.2014 um 21:57 hat Eric Blake geschrieben: > On 05/06/2014 01:30 PM, Max Reitz wrote: > > If the filename given to bdrv_open() is prefixed with "json:", parse the > > rest as a JSON object and use the result as the options QDict. > >=20 > > Signed-off-by: Max Reitz > > --- > > block.c | 41 +++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 41 insertions(+) > >=20 >=20 > > /* > > * Opens a disk image (raw, qcow2, vmdk, ...) > > * > > @@ -1337,6 +1364,20 @@ int bdrv_open(BlockDriverState **pbs, const char= *filename, > > options =3D qdict_new(); > > } > > =20 > > + if (filename && g_str_has_prefix(filename, "json:")) { > > + QDict *json_options =3D parse_json_filename(filename, &local_e= rr); > > + if (local_err) { > > + ret =3D -EINVAL; > > + goto fail; > > + } > > + > > + qdict_join(options, json_options, true); > > + assert(qdict_size(json_options) =3D=3D 0); >=20 > Would it be better to pass false to qdict_join(), and then raise an > error if the user specified conflicting options? For example (untested, > just typing off the top of my head here), >=20 > -drive > file=3D'json:{"driver":"qcow2","file.filename":"foo","backing.file.driver= ":"raw"}',backing.file.driver=3Dqcow2 >=20 > looks like it specifies conflicting backing.file.driver options. > Passing true means that qdict_join silently overwrites the value in > options to instead be the value in the json string; passing false means > you could flag the user error. Isn't the more realistic case, that 'file' is actually the backing file string stored in an image, and the overwriting option comes from the command line? In this case, I think we want to allow overriding the option stored in the qcow2 file. Kevin --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTafFeAAoJEH8JsnLIjy/WfiQP/i9UJB7XpbXISNClKfUzIQey TEBmrusq/OHppYSsz5rot+p+WWfe4b4ZbBvz0FJj7hjExPWpoy0pi7oTPpfNvGuQ sflPUWe+FksrnP3/iphZen0OBD14FJcP+dzGgnQuJjxV3N8eZmtPueSnGIjsNXVn boZVOtZ9dyMOh9e/sPKgIgdkUkEmSYSxXx2FqRofiXsOZ3cHlRRfprZv8e4vJgGL mtmFICklUPYS7oVLCfD37oq/WwpOWKbdYE9Caym2pNtqJ0SvHacF1ik8askO+8uX s+UdCC8u2hb7J/1V68oTUvjHLCPHZBfhgduXjH1lWAjrYin5hOu7+MK5k+EiSrJi eRKKitXxonYJi2k2OziNunZnYH+0cjW35QYD1rBDJD2WG+8r+SFAs2koFpFaQdeL IsdQgN/8jUYCE+h4LCjd0FVTblbDEjBaBnrI6H1dSVpNsb0lcwaJkkZJ53iLp+wi DHnhhkYHUbgSxWap635uxqwEgtET90rExOlzjL5UkJqkRkz+SYZNiC+rPt16WVdY gM8yJPOV2P/fjduayfKyvyCoZzZ09UC3rrfglu1MaSufuKV/Eabhs1RIWdOFVeXQ QATYxkqgl/O+dpty5fgZXewbDLTcn7dnbq+OJMD03v+P/GFIt1UEygA3HUfgZ9Uh O2eR0Ev4xRd63iE13HaW =f4Fx -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ--