From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56642) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWjme-0005xY-TR for qemu-devel@nongnu.org; Tue, 01 Sep 2015 07:31:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWjmd-0001hX-SE for qemu-devel@nongnu.org; Tue, 01 Sep 2015 07:31:24 -0400 Date: Tue, 1 Sep 2015 13:31:11 +0200 From: Kevin Wolf Message-ID: <20150901113111.GB4304@noname.redhat.com> References: <457103c2204e849aea3b83ffd78fad049d8d923d.1441014844.git.berto@igalia.com> <55E4B0CC.6070906@redhat.com> <55E4B374.70800@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <55E4B374.70800@redhat.com> Subject: Re: [Qemu-devel] [PATCH 1/1] block: Allow passing BlockdevOptions to blockdev-snapshot-sync List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-block@nongnu.org, Alberto Garcia , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 31.08.2015 um 22:05 hat Eric Blake geschrieben: > On 08/31/2015 01:53 PM, Max Reitz wrote: >=20 > > Design question: Would it make sense to instead add a "reference" mode > > to blockdev-snapshot-sync where you can specify a BDS's node-name > > instead of snapshot-file to use an existing BDS as the new top layer, > > ideally an empty one? >=20 > Indeed - then blockdev-add can be used to create an unattached BDS (with > all appropriate options), and blockdev-snapshot-sync would then attach > that BDS as the snapshot-file that wraps an existing BDS (without > needing to worry about options). Yes, this is what we should do. The existing blockdev-snapshot-sync should really have been called something like drive-snapshot, it doesn't belong in the blockdev-* family of commands which works only with existing nodes. > >> +++ b/qapi/block-core.json > >> @@ -697,11 +697,18 @@ > >> # > >> # @mode: #optional whether and how QEMU should create a new image, de= fault is > >> # 'absolute-paths'. > >> +# > >> +# @options: #optional options for the new device, with the following > >> +# restrictions for the fields: 'driver' must match the value > >> +# of @format, > >=20 > > As said above, I'd rather make specifying both @options and @format > > exclusive. > >=20 > > Maybe there is even some QAPI magic to enforce that (and for > > 'node-name', too), I don't know... >=20 > Not that I know of at the moment, but not to say we can't add some. The > closest we can get is with a flat union, but that requires a > non-optional discriminator field. Maybe we can tweak qapi to make the > discriminator optional (with a default value). Thankfully, it sounds > like Markus' work on introspection would at least let management apps > learn about a new 'options' argument. Let's avoid such magic and instead add a new, clean blockdev-* style command. Maybe call it simply blockdev-snapshot; the -sync part was added because we knew it wouldn't be the final version of the command. Now we don't have any bdrv_open() in it any more that could by synchronous or asynchronous. Kevin --wac7ysb48OaltWcw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV5Yx/AAoJEH8JsnLIjy/WxhgQAMpktsgu2bA1xWaIZVHxxapt AMtT48yCY0tl2id8vq2wEHoGPmyHRpG3hqQ0ZWWYbeAtU/2eR21TiuBQLHYOK2m2 ib8t65e99B1/hRi/E58jUUVf5VftnZvZOWGtzelvBcGrPQUX9AHXpTkA9RMtZIwR wAO0lrFqMVrtfgcn6fyY2PjE6Jx6hE7u8IBo1u49BAroz1LerviMq9sGqPfseBUq XPqus218EtmVrmiqM0s+/ApJeI8i85XhxsVGjTqQcmfSocTGxQn6LMk9IRRcCBye B3wZgyrw1I0SWBSS764BrUGtK2ybg8ezllIRhMkPbcIJZAnY7eJbaUNVfB31Xk1G kSTvAq/xuWgCM3lrj3uW0eNIDGjttJefu56CRi+pDClLATdnTYqgQZk4JtMJEceD e3EWi7+q/zehbhQ4fWFx41Eeoc8nfB/RfJ9PY+W3JvFoobbuJSfEYxUolM8958d3 Q/JqOIWABWeRM6bOfbohWJNu5SdgbdK2oJtWYjLl8XIZuSwdyUlwMmFYm8WvBvvs AU15ohKedFtGvE3Qum1yOWsR8lXVjQDW50xAHBA2OQi62VlTUWv+2AhCILjhfMvk +4Aw13UdSdLWsztdq6bWXaUIwVIW+c1BmJECG78u39EYliWMlm44WTcoD2C7gGnp DJjy7G7WR+1pXXV2glre =wDFU -----END PGP SIGNATURE----- --wac7ysb48OaltWcw--