From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnW8p-0005cu-Q1 for qemu-devel@nongnu.org; Sat, 17 Oct 2015 14:23:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnW8p-0007Qs-0V for qemu-devel@nongnu.org; Sat, 17 Oct 2015 14:23:39 -0400 References: <8dc2b9b2a8c5307eba7fafa2dee8f6e8ef17a26c.1444743418.git.berto@igalia.com> From: Max Reitz Message-ID: <5622921E.40604@redhat.com> Date: Sat, 17 Oct 2015 20:23:26 +0200 MIME-Version: 1.0 In-Reply-To: <8dc2b9b2a8c5307eba7fafa2dee8f6e8ef17a26c.1444743418.git.berto@igalia.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m8XV2QdfU7lT5M2c23CPERfX3idsXGKsx" Subject: Re: [Qemu-devel] [PATCH 2/3] block: Add 'blockdev-del' QMP command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi , Markus Armbruster , qemu-block@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m8XV2QdfU7lT5M2c23CPERfX3idsXGKsx Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 13.10.2015 15:48, Alberto Garcia wrote: > This is the companion to 'blockdev-add'. It allows deleting a > BlockBackend with its associated BlockDriverState tree, or a > BlockDriverState that is not attached to any backend. >=20 > In either case, the command fails if the reference count is greater > than 1 or the BlockDriverState has any parents. >=20 > Signed-off-by: Alberto Garcia > --- > blockdev.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > qapi/block-core.json | 21 +++++++++++++++++++++ > qmp-commands.hx | 36 ++++++++++++++++++++++++++++++++++++ > 3 files changed, 99 insertions(+) >=20 > diff --git a/blockdev.c b/blockdev.c > index 2360c1f..c448a0b 100644 > --- a/blockdev.c > +++ b/blockdev.c > @@ -3402,6 +3402,48 @@ fail: > qmp_output_visitor_cleanup(ov); > } > =20 > +void qmp_blockdev_del(const char *device, Error **errp) > +{ > + AioContext *aio_context; > + BlockBackend *blk; > + BlockDriverState *bs; > + > + blk =3D blk_by_name(device); > + if (blk) { > + bs =3D blk_bs(blk); > + aio_context =3D blk_get_aio_context(blk); > + } else { > + bs =3D bdrv_find_node(device); > + if (!bs) { > + error_setg(errp, "Cannot find block device %s", device); > + return; > + } > + blk =3D bs->blk; After seeing testBlockBackendUsingNodeName() in patch 3, I don't know about this. We often have this notion of "If you need a BDS, you can specify both the BB and the node name", but here it's the other way around: One "needs" a BB (at least that's what the command will work on) and one gets it by specifying a node name. That seems a bit strange to me= =2E Max > + aio_context =3D bdrv_get_aio_context(bs); > + } > + > + aio_context_acquire(aio_context); > + > + if (bs && bdrv_op_is_blocked(bs, BLOCK_OP_TYPE_DRIVE_DEL, errp)) {= > + goto out; > + } > + > + if (blk_get_refcnt(blk) > 1 || > + (bs && (bs->refcnt > 1 || !QLIST_EMPTY(&bs->parents)))) { > + error_setg(errp, "Block device %s is being used", device); > + goto out; > + } > + > + if (blk) { > + blk_unref(blk); > + } else { > + bdrv_unref(bs); > + } > + > +out: > + aio_context_release(aio_context); > +} > + > BlockJobInfoList *qmp_query_block_jobs(Error **errp) > { > BlockJobInfoList *head =3D NULL, **p_next =3D &head; --m8XV2QdfU7lT5M2c23CPERfX3idsXGKsx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWIpIeAAoJEDuxQgLoOKytyZQIAIb/qy9uwgDmu279fBriRlIp nOI9ADUPlnbluCpZUh/9CFvwrNM1u/KUXsf3+RIpMTzkITkCiptEIBRrc0u5g1Lx G163uBSQnJuEORAUON6WpiJfK4tqRt6+BJUuUMfSk+s7aw3tYv34o5urQMWwUKYS 5o4A+pPH1d62pUFxI1zfM1JG1UvzRMHfRQAg2YAdwf5mdg8rc8GRpHyfcf1Pz5ry KT+f5hWxJHtVc/+oNfQMWMYUGktw2ODzmvb0SGmZEZ6p46pKf2YaNwqZ6a+9mMGp byL9OFI73dKJ7RG2D4jLpH5bH2GODPJRduUT3VkHzkA4TSk0og5XJbNagefYxsM= =LWtS -----END PGP SIGNATURE----- --m8XV2QdfU7lT5M2c23CPERfX3idsXGKsx--