From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwcK2-0005R2-2Y for qemu-devel@nongnu.org; Thu, 04 Dec 2014 14:44:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XwcJx-0003DH-45 for qemu-devel@nongnu.org; Thu, 04 Dec 2014 14:44:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwcJw-0003DD-SJ for qemu-devel@nongnu.org; Thu, 04 Dec 2014 14:44:13 -0500 Message-ID: <5480B985.4050708@redhat.com> Date: Thu, 04 Dec 2014 12:44:05 -0700 From: Eric Blake MIME-Version: 1.0 References: <87vbltvpl0.fsf@blackfin.pond.sub.org> <20141203103041.GB4404@noname.str.redhat.com> <87k327e7dp.fsf@blackfin.pond.sub.org> In-Reply-To: <87k327e7dp.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UWLbkPC0g4Hs10CkXfaWwWXP3HbAh7QkJ" Subject: Re: [Qemu-devel] Review of monitor commands identifying BDS / BB by name List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Kevin Wolf Cc: Fam Zheng , jcody@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com, Stefan Hajnoczi , benoit.canet@nodalink.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UWLbkPC0g4Hs10CkXfaWwWXP3HbAh7QkJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/04/2014 08:56 AM, Markus Armbruster wrote: >=20 > @device is a sub-optimal name for this single parameter. Either we > accept that and move on, or we deprecate it in favor of a new parameter= > with a better name. I guess the better name isn't worth that much > trouble, in particular since the command name is already ugly. >=20 > When @node-name is given, @device must not be given. So @device is > mandatory *except* in the @node-name usage we retain for compatibility.= > Deprecate the usage. >=20 > Command documentation could then look like this: >=20 > ## > # @block-resize > # > # Resize a block image while a guest is running. > # > # @device: the name of the block backend or node to resize (node names > # supported since 2.3) > # > # @size: new image size in bytes > # > # Deprecated usage (since 2.3): > # > # @device: #optional the name of the block backend to resize > # > # @node-name: #optional name of the node to resize (since 2.0) > # > # Either @device or @node-name must be set but not both. But this isn't discoverable. You aren't changing whether any parameters are optional, only enhancing the semantics of existing parameters. How is libvirt supposed to know if qemu is old (node names have to go through node-name) or new (node names are preferred through device)? Just blindly try the 'device' argument, and if it fails, fall back to an attempt with node-name? On the other hand, if 'node-name' becomes the preferred interface, then libvirt has a solution: if node-name is present (it is easy during up-front QMP probing to determine whether 'node-name' is a recognized optional argument or an unknown argument), then always use node-name. As long as libvirt always names the nodes of each device (which it should be doing, but that's a patch series for another day and another list), then a device lookup is never needed. If 'node-name' is not present, then only the 'device' form is supported, and libvirt can only manage the top image of a backend (but can make that point obvious to the end user that they should upgrade qemu for more functionality). > Let's get the easy case out of the way first: a query that reports only= > backend properties and not node properties can return an array where > each element carries a backend name, like query-block does now. >=20 > For queries that report node properties, we have a couple of options: >=20 > * Flat array with node names >=20 > Like current query-named-block-nodes. >=20 > Can't report on nodes without names. Jeff's project to give all node= s > names would moot this issue. I could live with this. >=20 > * Array of trees mirroring the actual node forest, >=20 > Similar to current query-blockstats. >=20 > Tree roots correspond to backends, and backends have names. >=20 > Unfortunately, the nodes don't actually form a forest: node trees may= > be shared. To turn it into make a forest, we'd have to duplicate the= > shared trees. >=20 > * Hybrid: array of trees, but named sub-trees are represented by name >=20 > Like the previous one, except the recursion stops at named nodes. > Instead of including such a sub-tree, we reference it by name, then > add it to the array if it's not already there. This one seems like it might be easier for avoiding the reconstruction of relationships; but if management doesn't already know relationships, I'm not sure it is worth the complexity. >=20 > "Flat array" seems simplest. Simplest to implement. Management can't easily reconstruct the tree, but for looking up information about a known node, iterating over the simpler structure will be faster than trying to find a known node in a complex structure. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --UWLbkPC0g4Hs10CkXfaWwWXP3HbAh7QkJ 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 iQEcBAEBCAAGBQJUgLmFAAoJEKeha0olJ0NqUcYH/i2HsGbrzJW7wE5rBc8774l0 xmC2sO8GFGW1fpfCnhXvo/UrX5KRl5X9m0WsWPH1qZBxNnbUpZ4nra7yJBLvk1FI xChgWCPGDG5R61lkPQYilVXS7XOxEWmOD4CmNOHR3eFuW53kfU5Por8T/vz6ez4f DHnWE6D+/9Dw/Dydl4V6lhWDOAre+cAuIOpklTf7TtLptMMnjk+he0K9xpwuvg5h 7Ny+Na9IjeVGGec/qzhVnGdzQW4lZL1+stxJUC+nSpjEHRQLlpfN/0KcUvhCi7Y/ TTURLgWqAbY9KfM8RW+q/7+nL6n0V4TqYQMdKCPz9kH6eRSPPu8rjCJZEBY9m+E= =B6kE -----END PGP SIGNATURE----- --UWLbkPC0g4Hs10CkXfaWwWXP3HbAh7QkJ--