From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VcGCA-00050W-8h for qemu-devel@nongnu.org; Fri, 01 Nov 2013 10:59:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VcGC5-0006Rk-CR for qemu-devel@nongnu.org; Fri, 01 Nov 2013 10:59:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VcGC5-0006Rd-3t for qemu-devel@nongnu.org; Fri, 01 Nov 2013 10:59:25 -0400 Message-ID: <5273C1C8.4010601@redhat.com> Date: Fri, 01 Nov 2013 08:59:20 -0600 From: Eric Blake MIME-Version: 1.0 References: <20131028154038.GG2890@irqsave.net> <87eh72eumr.fsf@blackfin.pond.sub.org> <52715D2F.8000109@redhat.com> <20131101105139.3635bd82@redhat.com> In-Reply-To: <20131101105139.3635bd82@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9XNV3HnqQA83SwDkD0nLfncRshx02OFcO" Subject: Re: [Qemu-devel] How to introduce bs->node_name ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: =?UTF-8?B?QmVub8OudCBDYW5ldA==?= , kwolf@redhat.com, Markus Armbruster , stefanha@redhat.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9XNV3HnqQA83SwDkD0nLfncRshx02OFcO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/01/2013 08:51 AM, Luiz Capitulino wrote: > On Wed, 30 Oct 2013 13:25:35 -0600 > Eric Blake wrote: >=20 >> On 10/30/2013 07:49 AM, Markus Armbruster wrote: >> >>> >>> 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. >>> >>> CON: Existing parameter "device" becomes compatibility cruft. >>> >>> PRO: Clean and obvious semantics (in my opinion). >> >> I like this one as well. >=20 > Does this proposal makes "device" optional for existing commands? If it= > does then I'm afraid it breaks compatibility because if you don't > specify a device you'll get an error today. Changing from error to success is not backwards-incompatible. Old applications will ALWAYS supply device (because it used to be mandatory). That is, a management application that was intentionally omitting 'device' and expecting an error is so unlikely to exist that we can consider such a management app as buggy. For more examples of conversion from error to success, consider the 'block-commit' command. As introduced in 1.3, we did not yet have the implementation to commit the current image. But we designed the command with a view to the future (which we are nearly at, by the way, although I don't know if it will make 1.7 or be delayed to 1.8). In fact, we specifically made the 'top' argument mandatory at the time, and documented that if 'top' was the active layer that the command would fail; but with the full intent of removing the error and instead succeeding once we implement full commit; we also discussed the possibility in the 1.3 time-frame that 'top' could be made optional once block-commit could manage the current image. >=20 > Have you considered adding new commands instead? I'm still not convinced we need new commands yet. But again, proposing the QMP schema first will make that clearer. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --9XNV3HnqQA83SwDkD0nLfncRshx02OFcO 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/ iQEcBAEBCAAGBQJSc8HIAAoJEKeha0olJ0Nq60cH/R2Tc1XivplXiXPzXVukQyaT +9zg0p9BGor2HlkkgVBe+0+vo2rM2Y7LkPpRWtr7fqNcEXM063T2QT1JVZbVv3Z6 LJCjScKNS3UPn3fgiI/PZrzHtqFQzKYUK/xeGh9Yeti9ZXxzVSm49pGykqpLgUT+ C2+OCYOIvq0yctQkQBxm618dXq9MeZhLPqgUaMtqRKE5fvK7+Xn76+dPCQFBtvdD FSpN8GShBp+6lAb9XUQ587CGAHB55F+bmFE5eyrU6zTt2Wyu/98XyafNYrrlZCDm B5Hg5M8vJ3n9yONzm/NkttKcoW3VjKiX/UdioFw3kPfW3+QO+Ly9DS5P4PeZxUI= =Fd8n -----END PGP SIGNATURE----- --9XNV3HnqQA83SwDkD0nLfncRshx02OFcO--