From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2rKD-0001Ul-Lh for qemu-devel@nongnu.org; Tue, 17 May 2016 22:35:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b2rKC-0007TU-HH for qemu-devel@nongnu.org; Tue, 17 May 2016 22:35:05 -0400 References: <1463532149-11625-1-git-send-email-jsnow@redhat.com> <20160518021825.GB1864@ad.usersys.redhat.com> From: Eric Blake Message-ID: <573BD4D1.8090103@redhat.com> Date: Tue, 17 May 2016 20:34:57 -0600 MIME-Version: 1.0 In-Reply-To: <20160518021825.GB1864@ad.usersys.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6knUGWfnnJ1F0vUIJH2MHbwwJA4WPJgFR" Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] block: clarify error message for qmp-eject List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , John Snow Cc: armbru@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org, mreitz@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6knUGWfnnJ1F0vUIJH2MHbwwJA4WPJgFR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/17/2016 08:18 PM, Fam Zheng wrote: > On Tue, 05/17 20:42, John Snow wrote: >> If you use HMP's eject but the CDROM tray is locked, you may get a >> confusing error message informing you that the "tray isn't open." >> >> As this is the point of eject, we can do a little better and help >> clarify that the tray was locked and that it (might) open up later, >> so try again. >> >> It's not ideal, but it makes the semantics of the (legacy) eject >> command more understandable to end users when they try to use it. >> >> if (!blk_dev_has_removable_media(blk)) { >> error_setg(errp, "Device '%s' is not removable", device); >> - return; >> + return -ENOTSUP; >> } >> =20 >> if (!blk_dev_has_tray(blk)) { >> /* Ignore this command on tray-less devices */ >> - return; >> + return -ENOSYS; >=20 > I'm not sure how acceptable it is to leave errp untouched while setting= ret > code to non-zero. Markus? You're basically returning a tri-state: errp set (fatal, error issued), 0 (success, no error needed), or errp clear and negative (potential error, but caller must decide). It's unusual enough that you probably ought to document it at the top of the function, and it may mess with Markus' pending work to return status codes from functions taking Error *= *. It might also be worth considering using a POSITIVE return value when not setting an error code, so that a quick <0 check is synonymous with error set, 0 remains the code for complete success, and the locked tray with a retry now has an identifiable sentinel - particularly since you don't care about what errno values were in use except for EINPROGRESS. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --6knUGWfnnJ1F0vUIJH2MHbwwJA4WPJgFR 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXO9TRAAoJEKeha0olJ0NqsZ8H/2NQIxiSsGZxgDOFPAWAbmUh ltQq3e7zWabWukVFabyqZraF/Lpdaxcao4pY57vE69dp0WYxiT4eoOr/d896z66Y ECw7OgJvV7bJaG4GVbv76AE7r2TeVrJ6EYS0LR2bYiNLBWPr+vz09xsBH2oDl5u/ n9hHgTLgTsnpPU9IsRjJhs83sBWEmSxn9MYvFhiV0weedvZGJafx3FWAsHp2QF0u bg5QpQqCG8lF1s1tp70eUHY9/T2MBOtPFNtaBMU6aIYos81cAJh3+6Wrqlt1qYsF PY04IU+rDfsuUCA6JGs8aaBFjWkTlXvdtDvnwSHuJD9EKlOV2qZhoFqLunlvHXA= =EVQw -----END PGP SIGNATURE----- --6knUGWfnnJ1F0vUIJH2MHbwwJA4WPJgFR--