From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSR33-0000aP-MS for qemu-devel@nongnu.org; Wed, 27 Jul 2016 11:47:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSR2z-0000vU-99 for qemu-devel@nongnu.org; Wed, 27 Jul 2016 11:47:04 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:58714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSR2z-0000vK-01 for qemu-devel@nongnu.org; Wed, 27 Jul 2016 11:47:01 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u6RFioi5028551 for ; Wed, 27 Jul 2016 11:46:59 -0400 Received: from e06smtp09.uk.ibm.com (e06smtp09.uk.ibm.com [195.75.94.105]) by mx0a-001b2d01.pphosted.com with ESMTP id 24dsrqq7dv-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 27 Jul 2016 11:46:58 -0400 Received: from localhost by e06smtp09.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 27 Jul 2016 16:46:56 +0100 References: <1468845016-43468-1-git-send-email-pasic@linux.vnet.ibm.com> <1469532873-78542-1-git-send-email-pasic@linux.vnet.ibm.com> <7c4bdb1e-f0aa-4a07-2780-37f4f92c6665@redhat.com> <57979B63.1060505@linux.vnet.ibm.com> <5798ABB4.1070505@linux.vnet.ibm.com> <6a7179a7-b1b4-c379-00df-e1e9d25bccb3@redhat.com> From: Halil Pasic Date: Wed, 27 Jul 2016 17:46:12 +0200 MIME-Version: 1.0 In-Reply-To: <6a7179a7-b1b4-c379-00df-e1e9d25bccb3@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lhgX2EinJ3dLiTBOTniUPBEwvjaPrhksE" Message-Id: <5798D744.1090006@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v2 1/1] block: improve error handling in raw_open List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-block@nongnu.org Cc: Kevin Wolf , Cornelia Huck , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lhgX2EinJ3dLiTBOTniUPBEwvjaPrhksE From: Halil Pasic To: Max Reitz , qemu-block@nongnu.org Cc: Kevin Wolf , Cornelia Huck , qemu-devel@nongnu.org Message-ID: <5798D744.1090006@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v2 1/1] block: improve error handling in raw_open References: <1468845016-43468-1-git-send-email-pasic@linux.vnet.ibm.com> <1469532873-78542-1-git-send-email-pasic@linux.vnet.ibm.com> <7c4bdb1e-f0aa-4a07-2780-37f4f92c6665@redhat.com> <57979B63.1060505@linux.vnet.ibm.com> <5798ABB4.1070505@linux.vnet.ibm.com> <6a7179a7-b1b4-c379-00df-e1e9d25bccb3@redhat.com> In-Reply-To: <6a7179a7-b1b4-c379-00df-e1e9d25bccb3@redhat.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 07/27/2016 04:37 PM, Max Reitz wrote: >> Now if you examine #1 drive_new(all_opts,block_default_type) you see, >> > there is no errp argument and if you examine the code you see that t= he >> > error from blockdev_init which gets propagated properly to this poin= t >> > gets "handled" by error_report_err (in QMP context! so does not much= >> > good on this code path). AFAIU this can not work. Or am I wrong? > drive_add is an HMP command. There's no other way for it to emit errors= =2E >=20 > Strictly speaking, HMP commands are not supposed to be used by > management applications like libvirt (the "H" stands for "human", after= > all). QMP's "human-monitor-command" is just a workaround because there > are some HMP commands for which we do not have fully working QMP > replacements yet. One such example is indeed drive_add, because as > Markus correctly pointed out, blockdev-add is still considered experime= ntal. >=20 > So we're still in the awkward spot of only having a legacy command > (drive_add) and an experimental command (blockdev-add); and we have bee= n > in that spot for quite a while now (more than two years, I think). I > think we're getting rather close to getting blockdev-add stable, but > then again I'm afraid that might be something we've been thinking for > the past two years. >=20 > Max >=20 My primary concern was the function drive_new which does not propagate/report errors adequately under certain conditions, and although there are multiple usages of drive_new after looking into them I'm getting convinced that they are OK -- besides the one pointed out here. I read your comment as: "We are already working on this. It is best for you to ignore the problem.". Is my reading correct? If it is I can live with that. Thanks for the explanations. Cheers, Halil --lhgX2EinJ3dLiTBOTniUPBEwvjaPrhksE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJXmNdtAAoJEA0vhuyXGx0A24YQAI4Gf0koUJU/ToRvIXhkWQDR ytm1h34hMS19nErismPXs14YmOKz2kutLob9DNovGQNwh6lOuALlr/A4IcmVPrlX ec0t49oz8Fi/N0lXckUxqymIBQRRqo4F+V+LFmuuH/eUoNFwybx9ZqUvyqSMcID7 kPZGeMi2jSAerxX3nvA7G9iwLzEJd6rWmQPUbncBxHH4oEaydeMXqJok/eiImvSy MNBZjSQiIZ2/HpdH3bzwRkQajE/sp80puDvDa3z9eeMo+yMmDbycPDel8/C9EjYn aQrgCJukJnMP4xV8rsnCKOY1Yk5WC1G00ofHxOwv40MgqHeBi03ga39bvBi4+xX+ geveGwkzWqTtg429oMmWVZ+nQgok/pSXJdIgUDjPxZGXM3L4s1fIedqBCIpPp0Mi ZUgnb2C7VzOvFS0JrCA2aSZGGgEQJnmHzPsCCtsCE3AMJ5EEbH4wVuykRtJk/sW2 k3XoRV/Eo5P0rdgwJFgOgL3bmLFK1Ej0wZ3GprtL+ZflnGybr8mW9y3LNIQxuF2U BmzrsqjC2C91rBz+H39EI/Tgk1bJQd/cKZA7KD4tyd5PAYjjxMm5XEnycJhv9xYW 83uWJILO81bOuMn34YLiIKutxokBkvhyd/AEbvVy5UQqvXKSgKLZDMMh4MutnnlD DN7Qj10J3ljHkm9JVIQA =Rppo -----END PGP SIGNATURE----- --lhgX2EinJ3dLiTBOTniUPBEwvjaPrhksE--