From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xwp3T-0007XH-L8 for qemu-devel@nongnu.org; Fri, 05 Dec 2014 04:20:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xwp3N-0002l2-Bl for qemu-devel@nongnu.org; Fri, 05 Dec 2014 04:20:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xwp3N-0002ku-2M for qemu-devel@nongnu.org; Fri, 05 Dec 2014 04:19:57 -0500 Date: Fri, 5 Dec 2014 10:19:50 +0100 From: Kevin Wolf Message-ID: <20141205091950.GA4026@noname.str.redhat.com> References: <87vbltvpl0.fsf@blackfin.pond.sub.org> <20141203103041.GB4404@noname.str.redhat.com> <87k327e7dp.fsf@blackfin.pond.sub.org> <5480B985.4050708@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <5480B985.4050708@redhat.com> 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: Eric Blake Cc: Fam Zheng , qemu-devel@nongnu.org, jcody@redhat.com, Markus Armbruster , mreitz@redhat.com, Stefan Hajnoczi , benoit.canet@nodalink.com --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 04.12.2014 um 20:44 hat Eric Blake geschrieben: > On 12/04/2014 08:56 AM, Markus Armbruster wrote: >=20 > >=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. >=20 > 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? >=20 > 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). I thought libvirt didn't use any node names yet? Then it should probably never try node-name, but only device. There's probably little reason to resize a non-root node anyway, so if you can't do that with qemu < 2.3, I don't think it would be a big problem. > > 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 nodes > > names would moot this issue. >=20 > I could live with this. >=20 > >=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. >=20 > 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 > >=20 > > "Flat array" seems simplest. >=20 > 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. I think what we need to add in the flat array is references (by name) to the child nodes. The approach is a bit complicated by the fact that we already include random subtrees that appeared useful in some places. Kevin --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJUgXi2AAoJEH8JsnLIjy/Wqm4QAK7KCFbcfxzwNolLwV0kuKmk 0UCF/YxULI8O/6N62u/mt32xLOU5zwhfwY0NK2L5UICEm+rjqBa0A4RSanEvvutY yTTdXPbEEKu4pCcajSCgJIElGKfmsNFdjgxRxAebt18JdcTwKlm9nM5H+SO5rZzh 9LSwUQq+ihRiILzLu9IgYxcHqgbeSJpsw9xViWfNyaAwPON3pLMdbM7nI/xDsxyf Gs+iaMr5g2q6/9sKndO0SP8XwFzJsEsZQxLlZ30o80n0csvMoQlNDDIpwe6yVaDF 9IgpFgWcEjbWMrPHGoZrCsdnwsfiv6KMnjz2tHpUBSZDa60thvkYyXFTPAurOD4g 4GEoUTh7F+UfL1EtpY2If/STOe7OIyzYNKbsHOF6jXnTl0nE0ut74C7r+W4BE4ph lnMpPlaifohta7XAeoMPdpmg34BoyjhOcKNnkXffQ4q213XMWKs7KfIqBKD7TcCU 4DvKpwL9OyC8/HBis07o/R+FCRh5KUkEQ3jXTSoQv5IxS1oqAnF/LzFR/NjtHi9K W6/qcHUJugNrTlKvWujgt/tH8bJxXo6UpowOs3VQg3FLPZ8Wdct1cijAJYEodS5I Wkm43JVIo6QHag/R5Q5fqB2aExy7MQ7IVEHmAz+ew+dwy80suWNowp4R0hFktCK7 Hi9gIdFyBaEvGxhSmz95 =sMP8 -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT--