From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxqNK-0006wR-6G for qemu-devel@nongnu.org; Fri, 20 Jun 2014 00:24:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxqND-0001jV-VE for qemu-devel@nongnu.org; Fri, 20 Jun 2014 00:24:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxqND-0001jN-Mk for qemu-devel@nongnu.org; Fri, 20 Jun 2014 00:24:23 -0400 Date: Fri, 20 Jun 2014 12:24:13 +0800 From: Stefan Hajnoczi Message-ID: <20140620042413.GC11029@stefanha-thinkpad.redhat.com> References: <526da734a5f3cffd2eb56accafdb4add38c75270.1403041699.git.jcody@redhat.com> <20140619085502.GR21236@stefanha-thinkpad.redhat.com> <20140619123019.GA6096@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1SQmhf2mF2YjsYvc" Content-Disposition: inline In-Reply-To: <20140619123019.GA6096@localhost.localdomain> Subject: Re: [Qemu-devel] [PATCH v6 for 2.1 01/10] block: Auto-generate node_names for each BDS entry List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: kwolf@redhat.com, benoit.canet@irqsave.net, pkrempa@redhat.com, famz@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org --1SQmhf2mF2YjsYvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 19, 2014 at 08:30:19AM -0400, Jeff Cody wrote: > On Thu, Jun 19, 2014 at 04:55:02PM +0800, Stefan Hajnoczi wrote: > > On Tue, Jun 17, 2014 at 05:53:49PM -0400, Jeff Cody wrote: > > > Currently, node_name is only filled in when done so explicitly by the > > > user. If no node_name is specified, then the node name field is not > > > populated. > > >=20 > > > If node_names are automatically generated when not specified, that me= ans > > > that all block job operations can be done by reference to the unique > > > node_name field. This eliminates ambiguity in resolving filenames > > > (relative filenames, or file descriptors, symlinks, mounts, etc..) th= at > > > qemu currently needs to deal with. > > >=20 > > > If a node name is specified, then it will not be automatically > > > generated for that BDS entry. > > >=20 > > > If it is automatically generated, it will be prefaced with "__qemu##", > > > followed by 8 characters of a unique number, followed by 8 random > > > ASCII characters in the range of 'A-Z'. Some sample generated node-n= ame > > > strings: > > > __qemu##00000000IAIYNXXR > > > __qemu##00000002METXTRBQ > > > __qemu##00000001FMBORDWG > > >=20 > > > The prefix is to aid in identifying it as a qemu-generated name, the > > > numeric portion is to guarantee uniqueness in a given qemu session, a= nd > > > the random characters are to further avoid any accidental collisions > > > with user-specified node-names. > > >=20 > > > Reviewed-by: Eric Blake > > > Signed-off-by: Jeff Cody > > > --- > > > block.c | 16 +++++++++++++++- > > > 1 file changed, 15 insertions(+), 1 deletion(-) > >=20 > > Who is this feature for? > >=20 > > Human users: they'll need to read through query-named-block-nodes > > output to find the nodes they care about. This is pretty cumbersome and > > not human-friendly. > >=20 >=20 > Currently, that is how a human user would find the node-names. That > doesn't mean there might not be a new interface later on, that is more > human friendly. >=20 > And while a human parsing query-named-block-nodes isn't fun, I think > it is easier than a human assigning node-names to a graph, so it is > more human-friendly than the current system. >=20 > > Management tools: parsing query-named-block-nodes isn't trivial since > > the output can vary between QEMU versions (e.g. when we move I/O > > throttling to a block driver node there will be new internal nodes). > > Tools doing this should really use blockdev-add instead and assign their > > own node names. >=20 > Libvirt (and OpenStack) is already testing with these patches, and my > impression from Eric is that parsing the output of > query-named-block-nodes was less work than assigning node-names in > libvirt. >=20 > Can you expand a bit on moving i/o throttle to a block, and creating > new internal nodes? Currently I/O throttling is integrated into block.c. This was done because we had no clean way to add filter nodes (like I/O throttling, compression, encryption, etc) on top of the format and protocol nodes. Now we have almost reached the point where I/O throttling can be split off into a BlockDriver. When the feature is enabled an I/O throttling node will be added into the graph. When the feature is disabled, there will be no I/O throttling node in the graph. Stefan --1SQmhf2mF2YjsYvc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTo7dtAAoJEJykq7OBq3PI5VYH/0kKmz4W1jC+VOsl0QGBomvD SpWEFSCtnRKkv53aA5FaZF5fCMVBozRNhi5UohXH49B9/CKeR1v/1yCHW84rgxZy Nw/QV927Shvdt09gUEiZdrzfyrzCPO/oEhX3HOld30Ev6CKLyHaDeDB+grhVKLac GpenUrrhtWOTJp8+q7E30n85fw1vveoAVVPNTeclqrTV7gy3LYPoD9AuQd3oG+M3 Erbs4hn2oG3W7mAsvL0lJVGW7aQneolFSTCnL+d0N45157YCGvTffkLaixaLyS/B ZDFzqZT2FesWw+cyjP08gQx7dC90xUxZuZoCS17aSrweTtkava0Va3lzDEN2LPs= =lrio -----END PGP SIGNATURE----- --1SQmhf2mF2YjsYvc--