From: John Snow <jsnow@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com,
Kevin Wolf <kwolf@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/1] block: clarify error message for qmp-eject
Date: Fri, 20 May 2016 17:27:02 -0400 [thread overview]
Message-ID: <b5a69ef7-81aa-89f1-cf3b-5cc9fdb03668@redhat.com> (raw)
In-Reply-To: <87vb283hw9.fsf@dusky.pond.sub.org>
On 05/20/2016 10:48 AM, Markus Armbruster wrote:
> John Snow <jsnow@redhat.com> writes:
>
>> 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.
>>
>> Signed-off-by: John Snow <jsnow@redhat.com>
> [...]
>> @@ -2327,35 +2340,36 @@ void qmp_block_passwd(bool has_device, const char *device,
>> aio_context_release(aio_context);
>> }
>>
>> -void qmp_blockdev_open_tray(const char *device, bool has_force, bool force,
>> - Error **errp)
>> +/**
>> + * returns -errno on fatal error, +errno for non-fatal situations.
>> + * errp will always be set when the return code is negative.
>> + * May return +ENOSYS if the device has no tray,
>> + * or +EINPROGRESS if the tray is locked and the guest has been notified.
>> + */
>
> Returning or testing for positive errno instead of a negative one is a
> fairly common error. The more we can restrict use of positive errno
> codes to errno itself, the less likely such errors are.
>
> Moreover, I feel fatal vs. non-fatal is not for this function to decide.
> It's the caller's business. I'd return -errno on any error. If you
> need this function to also set an error, because it can do a better job
> than its callers, then set it on any error. If a caller wants to
> suppress a certain error, it can simply free the error. Clean
> separation of concerns, and a simpler interface.
>
>> +static int do_open_tray(const char *device, bool force, Error **errp)
>> {
>> BlockBackend *blk;
>> bool locked;
>>
>> - if (!has_force) {
>> - force = false;
>> - }
>> -
>> blk = blk_by_name(device);
>> if (!blk) {
>> error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
>> "Device '%s' not found", device);
>> - return;
>> + return -ENODEV;
>> }
>>
>> if (!blk_dev_has_removable_media(blk)) {
>> error_setg(errp, "Device '%s' is not removable", device);
>> - return;
>> + return -ENOTSUP;
>> }
>>
>> if (!blk_dev_has_tray(blk)) {
>> /* Ignore this command on tray-less devices */
>> - return;
>> + return ENOSYS;
>> }
>>
>> if (blk_dev_is_tray_open(blk)) {
>> - return;
>> + return 0;
>> }
>>
>> locked = blk_dev_is_medium_locked(blk);
>> @@ -2366,6 +2380,21 @@ void qmp_blockdev_open_tray(const char *device, bool has_force, bool force,
>> if (!locked || force) {
>> blk_dev_change_media_cb(blk, false);
>> }
>> +
>> + if (locked && !force) {
>> + return EINPROGRESS;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +void qmp_blockdev_open_tray(const char *device, bool has_force, bool force,
>> + Error **errp)
>> +{
>> + if (!has_force) {
>> + force = false;
>> + }
>> + do_open_tray(device, force, errp);
>> }
>>
>> void qmp_blockdev_close_tray(const char *device, Error **errp)
It already got applied, but I can change it to your preference. (Always
return an -errno and an Error, delete-and-free when we don't care about
it...)
--js
next prev parent reply other threads:[~2016-05-20 22:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-18 21:53 [Qemu-devel] [PATCH v2 0/1] block: clarify error message for qmp-eject John Snow
2016-05-18 21:53 ` [Qemu-devel] [PATCH v2 1/1] " John Snow
2016-05-18 22:05 ` Eric Blake
2016-05-19 1:24 ` Fam Zheng
2016-05-20 14:48 ` Markus Armbruster
2016-05-20 21:27 ` John Snow [this message]
2016-05-30 11:56 ` Markus Armbruster
2016-05-19 12:40 ` [Qemu-devel] [Qemu-block] [PATCH v2 0/1] " Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b5a69ef7-81aa-89f1-cf3b-5cc9fdb03668@redhat.com \
--to=jsnow@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).