From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55541) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X21Xr-0005hV-Ir for qemu-devel@nongnu.org; Tue, 01 Jul 2014 13:08:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X21Xn-0002Fn-1e for qemu-devel@nongnu.org; Tue, 01 Jul 2014 13:08:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X21Xm-0002Ff-PV for qemu-devel@nongnu.org; Tue, 01 Jul 2014 13:08:34 -0400 Message-ID: <53B2EB0F.2050402@redhat.com> Date: Tue, 01 Jul 2014 11:08:31 -0600 From: Eric Blake MIME-Version: 1.0 References: <1403889855-5740-1-git-send-email-armbru@redhat.com> <1403889855-5740-2-git-send-email-armbru@redhat.com> In-Reply-To: <1403889855-5740-2-git-send-email-armbru@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qvDO9XfAUMwl8Wb0CSP1CVo0C6iVKxbgV" Subject: Re: [Qemu-devel] [PATCH v2 2.1 1/3] blockjob: Fix recent BLOCK_JOB_READY regression List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , qemu-devel@nongnu.org Cc: kwolf@redhat.com, pbonzini@redhat.com, wenchaoqemu@gmail.com, stefanha@redhat.com, lcapitulino@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qvDO9XfAUMwl8Wb0CSP1CVo0C6iVKxbgV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/27/2014 11:24 AM, Markus Armbruster wrote: > Commit bcada37 dropped the (up to now undocumented) members type, len, > offset, speed, breaking tests/qemu-iotests/040 and 041. >=20 > Restore and document them. This fixes 040, and partially fixes 041. >=20 > Signed-off-by: Markus Armbruster > Tested-By: Benoit Canet > --- > blockjob.c | 6 +++++- > qapi/block-core.json | 15 ++++++++++++++- > 2 files changed, 19 insertions(+), 2 deletions(-) Nothing wrong with this commit, but a design issue that I've recently run into: what happens if management misses the BLOCK_JOB_COMPLETED event? How is it supposed to learn whether the job succeeded or failed? 'query-blockjobs' no longer reports the job (because it is completed), so all information about the job is lost. Normally, we've tried hard to make sure that all information learned from an event can also be polled (the ideal is use of events to minimize cpu overhead, but to rely on the poll in situations where events may have been lost such as on a libvirtd restart). Should we enhance job failure to be sticky, in that it not only causes an event, but also remains around so that it can be reported in the next 'query-blockjobs'? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --qvDO9XfAUMwl8Wb0CSP1CVo0C6iVKxbgV 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/ iQEcBAEBCAAGBQJTsusPAAoJEKeha0olJ0NqLn4H/AwHdjNL5z8X6AG2/S9veNBW I4uN41FaSbwES3+dGZvWsECJwMDgVq4DlzLrZK7Kv7hj+ZQURhHRmVATltCihmrc mSAz8u4laAgtJMAF1l9dr6CxBNCFOv9eu/zjJJ0AWSL/R1V39W/nCKML7WMs8yeo jOKeNs7dO5sVO1xzigk9bHtPMUF1n/LQIch/y9rAv4a3CCyORojX16cG6ppxDff3 W/areIfj95ZYNOf5XOtmqSC6zJCLzSH5jultuNSpdcM5X+EF9B3qesFH0dCcH3HZ UvtDeD7tnkz7Nm2/p+Svb0yNYs+qGygnR+YBjTvlI0LjX327VAeZW535ZOXacgI= =GKFP -----END PGP SIGNATURE----- --qvDO9XfAUMwl8Wb0CSP1CVo0C6iVKxbgV--