From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsItl-0003Ty-F9 for qemu-devel@nongnu.org; Wed, 04 Jun 2014 17:39:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsItf-0000DM-TE for qemu-devel@nongnu.org; Wed, 04 Jun 2014 17:39:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsItf-0000DB-Kn for qemu-devel@nongnu.org; Wed, 04 Jun 2014 17:38:59 -0400 Message-ID: <538F91EF.2010700@redhat.com> Date: Wed, 04 Jun 2014 15:38:55 -0600 From: Eric Blake MIME-Version: 1.0 References: <5da6a0b4d7cf0177bb5bf8e2e74a49769d90120c.1401886089.git.jcody@redhat.com> In-Reply-To: <5da6a0b4d7cf0177bb5bf8e2e74a49769d90120c.1401886089.git.jcody@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m2CuMGQGabDeiNSolljCrFdPcpwB8xxsO" Subject: Re: [Qemu-devel] [PATCH v4 05/10] block: Accept node-name arguments for block-commit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody , qemu-devel@nongnu.org Cc: kwolf@redhat.com, benoit.canet@irqsave.net, pkrempa@redhat.com, famz@redhat.com, stefanha@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m2CuMGQGabDeiNSolljCrFdPcpwB8xxsO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/04/2014 07:51 AM, Jeff Cody wrote: > This modifies the block operation block-commit so that it will > accept node-name arguments for either 'top' or 'base' BDS. >=20 > The filename and node-name are mutually exclusive to each other; > i.e.: > "top" and "top-node-name" are mutually exclusive (enforced) > "base" and "base-node-name" are mutually exclusive (enforced) >=20 > The "device" argument now becomes optional as well, because with > a node-name we can identify the block device chain. It is only > optional if a node-name is not specified. Stale paragraph; just delete it. [We may later want to add patches to make device optional, if we can figure out a solution for what to do when a BDS has more than one overlay; but that doesn't need to stall this series] >=20 > The preferred and recommended method now of using block-commit > is to specify the BDS to operate on via their node-name arguments. >=20 > This also adds an explicit check that base_bs is in the chain of > top_bs, because if they are referenced by their unique node-name > arguments, the discovery process does not intrinsically verify > they are in the same chain. >=20 > Signed-off-by: Jeff Cody > --- > blockdev.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++-= ------- > qapi-schema.json | 37 +++++++++++++++++++++++++++---------- > qmp-commands.hx | 31 +++++++++++++++++++++++-------- > 3 files changed, 97 insertions(+), 26 deletions(-) >=20 > - bs =3D bdrv_find(device); > - if (!bs) { > - error_set(errp, QERR_DEVICE_NOT_FOUND, device); > + /* argument combination validation */ > + if (has_base && has_base_node_name) { > + error_setg(errp, "'base' and 'base-node-name' are mutually exc= lusive"); > + return; > + } An alternative would have been to validate that both 'base' and 'base-node-name' resolve to the same BDS, but I like the simplicity of erroring out here. > + > + if (bdrv_op_is_blocked(bs, BLOCK_OP_TYPE_COMMIT, errp)) { > + return; > + } [unrelated to this commit - are we sure that the semantics of the commit blocker are correct? If we implement BDS reuse among multiple chains, consider what happens if I have: / sn1 <- sn2 base < \ file3 Even if there is no other block job operating on sn2 or its chain, we really want to block an attempt to merge file3 into base, as modifying base would corrupt both sn1 and sn2. That is, a BDS being a common backing between more than one chain should automatically behave as an op-blocker for commits - where the block is what you are committing into, not where you are committing from.] Reviewed-by: Eric Blake --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --m2CuMGQGabDeiNSolljCrFdPcpwB8xxsO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTj5HvAAoJEKeha0olJ0NqsY4H/28khPDTf9N9Xozh7uX7MdxO 52f/jtmFknLWYvj6wvQr5cQKtTHks8tV3vqlJ77299lmdZEu1kGasGUvAQtRmIZe skiXwL5vQk+7uZX9DFlAPghkdMwyryPwSKeP0asQEtLdsvEjrr0jDSICCBtQsljS fJASx00japWlx41t1keyMYtM0bhmqG2nCOxZPmxILvEd7CGt/6D6E251Sf4a1oHi s99x4cZVgUnjXC98ZLxz078y9RnokrimL2b1IZyUyO4UpOhT8T0L0pzw/miRB348 hfCEc/V3/HE7+B7PzyL21IORkgnFGQHadUfp7WcL6UMN5jxBJzsqdNcxH0Qn8YU= =VgG3 -----END PGP SIGNATURE----- --m2CuMGQGabDeiNSolljCrFdPcpwB8xxsO--