From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXtLN-0007wz-SC for qemu-devel@nongnu.org; Tue, 17 Mar 2015 11:23:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXtLH-0000dh-7q for qemu-devel@nongnu.org; Tue, 17 Mar 2015 11:23:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXtLH-0000dX-0U for qemu-devel@nongnu.org; Tue, 17 Mar 2015 11:23:39 -0400 Message-ID: <550846CF.10706@redhat.com> Date: Tue, 17 Mar 2015 09:22:55 -0600 From: Eric Blake MIME-Version: 1.0 References: <49b845c4a362ffd64ec78bbe0b165cd7addd2a4b.1424439295.git.berto@igalia.com> <20150305140958.GE5427@noname.redhat.com> <20150311163806.GA5883@igalia.com> <20150312154517.GB7029@noname.redhat.com> <20150317150028.GA21771@igalia.com> In-Reply-To: <20150317150028.GA21771@igalia.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5i2EDaiTvWT84cMqSgN5SMlsuRiOV7IKX" Subject: Re: [Qemu-devel] [PATCH 2/3] block: Add QMP support for streaming to an intermediate layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia , Kevin Wolf Cc: Jeff Cody , qemu-devel@nongnu.org, Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5i2EDaiTvWT84cMqSgN5SMlsuRiOV7IKX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/17/2015 09:00 AM, Alberto Garcia wrote: > The BlockJobInfo object returned by query-block-jobs identifies the > owner of the job using the 'device' field. If jobs can be in any > intermediate node then we cannot simply rely on the device name. We > also cannot simply replace it with a node name because 1) it might not > exist and 2) existing libvirt versions expect a device name. >=20 > So I see several alternatives: >=20 > a) Add a new 'node-name' field to BlockJobInfo. It's simple, > 'device' keeps the current semantics so we don't break > compatibility. >=20 > b) Make 'device' return the device name as it currently does, or > the node name if it's not present. The main problem is that > libvirt cannot easily know what to expect. On the other hand > since both device and node-name share the same namespace the > returned value is not ambiguous. If libvirt is new enough to create the block job via node name instead of device name, then it is also new enough to expect a node name instead of device name in the returned job information. That is, I'm okay with either: old libvirt: creates job using 'device' as a device name, status about the job is reported with 'device' as the device name new libvirt: creates job using 'device' as a node name, status about the job is reported with 'device' as the node name (no new parameter, 'device' is used on both creation and query as a [poorly-named] device-or-node, back-compat is obvious) or with: old libvirt: creates job using 'device' as a device name, status about the job is reported with 'device' as the device name new libvirt: creates job using 'node' as a node name, status about the job is reported with 'node' as the node name (new parameter; old usage remains the same, and new usage has proper naming, but now we have to track which name is in use) >=20 > c) Make 'device' return the same name that was used when the job > was created. It's maybe simpler for libvirt than option b), > but it would require us to remember how the job was created, > possibly in the BlockJob structure. This is personally my least > favorite option. If you're going to reuse 'device' on the creation, then reuse it on the reporting. >=20 > d) Create a new query command that returns a different data > structure. >=20 > I would opt for a) or b), but I'd like to hear if you have a different > opinion. I'm kind of leaning towards b). >=20 > Regarding the 'block-stream' command, I think the current option to > reuse the 'device' parameter to refer to either a device or a node > name is ok, so I'll go forward with that one. Particularly if we don't have two parameters for starting the job, then we don't need two parameters for reporting it. >=20 >> On the other hand, having an owner BDS for a block job is considered >> a mistake meanwhile because there is no clear rule which BDS to pick >> when the job involves more than one. >=20 > Does it really matter as long as all the operations blockers are > correctly set? >=20 >> In fact, without tying a job to a BDS, it could be just a background >> job instead of specifically a block job. >=20 > I don't understand what you mean by this. >=20 > Berto >=20 >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --5i2EDaiTvWT84cMqSgN5SMlsuRiOV7IKX 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVCEbPAAoJEKeha0olJ0Nqm0UH/iAj9luKwgRyEeBjT/MK8ABQ cl1JM+OYWM6xnpM5lsPM8y7cxUi4xmo5vgHqas1Ytxy6h2mLdsU9IdEvhJ2Bwqnz pXw+et42jx/TEM+jUYodj+l3hORnQ5/DVnRQ5XHYafxuPUulBeRxVCToJ2kfbfL2 UpGYARsHFEDD4+GZEtN+KWe5wpAlhYIu4ZiWQTBBBcAKRYqWGfOgJQGzPNh3pziR RXx8e37hoUN3M7gjDyU5bYla2i16cS8zQaXbZV3s5D5SwOncPbZtW6gdh+g4BXvR AD1MMfoNZ4qs2KD8TMGwOerKgs+OELCGdhLnqWBpvaV8fYSqEMwSoCCy018PAzg= =H46B -----END PGP SIGNATURE----- --5i2EDaiTvWT84cMqSgN5SMlsuRiOV7IKX--