From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbbOk-0003XU-QN for qemu-devel@nongnu.org; Wed, 30 Oct 2013 15:25:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VbbOf-0007rO-TZ for qemu-devel@nongnu.org; Wed, 30 Oct 2013 15:25:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbbOf-0007rI-GB for qemu-devel@nongnu.org; Wed, 30 Oct 2013 15:25:41 -0400 Message-ID: <52715D2F.8000109@redhat.com> Date: Wed, 30 Oct 2013 13:25:35 -0600 From: Eric Blake MIME-Version: 1.0 References: <20131028154038.GG2890@irqsave.net> <87eh72eumr.fsf@blackfin.pond.sub.org> In-Reply-To: <87eh72eumr.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9WBmVF5gArGk97KF3llvCtQgFv6ewF633" Subject: Re: [Qemu-devel] How to introduce bs->node_name ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , =?UTF-8?B?QmVub8OudCBDYW5ldA==?= Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9WBmVF5gArGk97KF3llvCtQgFv6ewF633 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/30/2013 07:49 AM, Markus Armbruster wrote: >=20 > The first proposal is to add another parameter, say "id". Users can > then refer either to an arbitrary BDS by "id", or (for backward > compatibility) to the root BDS by "device". When the code sees > "device", it'll look up the BB, then fetch its root BDS. >=20 > CON: Existing parameter "device" becomes compatibility cruft. >=20 > PRO: Clean and obvious semantics (in my opinion). I like this one as well. >=20 > The second proposal is to press the existing parameter "device" into > service for referring to BDS node_name. >=20 > To keep backward compatibility, we obviously need to ensure that > whenever the old code accepts a value of "device", the new code accepts= > it as well, and both resolve it to the same BDS. >=20 > What about situations where the old code rejects a value of "device"? > The new code may resolve it to a non-root BDS that happens to have that= > ID... >=20 > What about dynamic reconfiguration changing the root? Example: a > synchronous snapshot splices in a QCOW2, which becomes the new root. I= n > the current code, device_name refers to the new root. Wouldn't that > require the BDS ID of the old root moves to the new root? But that > would mean BDS IDs change! Having device_name tied to the BB, and ID tied to each BDS, seems much more workable in the long run. >> My personnal suggestion would be that non specified node-name would be= set to >> "undefined" meaning that no operation could occur on this bs. >=20 > Yes, that's how IDs work elsewhere. Agreed. > [QMP and HMP code using bdrv_find() snipped] >=20 > I think we should review with the QMP schema first, code second. Yes, get the interface right, and then it's easier to review the code that implements the interface. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --9WBmVF5gArGk97KF3llvCtQgFv6ewF633 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.4.15 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJScV0vAAoJEKeha0olJ0NqQ88H/j9Rzpjifx5JC9IQTWSCiCDw jvJzrDB1y0zog0FekmFKxEmWPzK8wqfWqR8fWME4M3g13WPF2SkgwF8j46w1modX n/u0Gxg6JpAtGvLuEyEGrQs4BgYig8bd8aUHqu5o8q3EhEQgOLbSThkxeoV2NO2n oAJ/B12VvoRj3WNeetRRHdVEBBGZe4pSUDyqCAUt5Y7CJAODxN+Eg/t9kDsUsLVG YAnz5GtjKxESqKj47pVArNpN9gt+kCzgnKPLfnD04EGbjXFVPLv7heoeXpJZgep3 nzOqEy1OKvd5vDHNO0yyrmzy2D56dXViI8zD0K/yVl6EJCqQxUV/Okzo0LkvLcQ= =2EEU -----END PGP SIGNATURE----- --9WBmVF5gArGk97KF3llvCtQgFv6ewF633--