From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Max Reitz <mreitz@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH 9/9] monitor/hmp: Prefer to use hmp_handle_error for error reporting in block hmp commands
Date: Tue, 28 Jan 2020 19:35:34 +0000 [thread overview]
Message-ID: <20200128193534.GG3215@work-vm> (raw)
In-Reply-To: <418004b0c3e8bf1c076a46d514f2267d971f6929.camel@redhat.com>
* Maxim Levitsky (mlevitsk@redhat.com) wrote:
> On Mon, 2020-01-27 at 14:44 +0100, Markus Armbruster wrote:
> > Maxim Levitsky <mlevitsk@redhat.com> writes:
> >
> > > On Wed, 2019-11-27 at 09:38 +0100, Markus Armbruster wrote:
> > > > Title is too long. blockdev-hmp-cmds.c will become
> > > > block/monitor/block-hmp-cmds.c in v2. With this in mind, suggest
> > > >
> > > > block/monitor: Prefer to use hmp_handle_error() to report HMP errors
> > > >
> > > > Maxim Levitsky <mlevitsk@redhat.com> writes:
> > > >
> > > > > This way they all will be prefixed with 'Error:' which some parsers
> > > > > (e.g libvirt need)
> > > >
> > > > Sadly, "all" is far from true. Consider
> > > >
> > > > void hmp_drive_add(Monitor *mon, const QDict *qdict)
> > > > {
> > > > Error *err = NULL;
> > > > DriveInfo *dinfo = NULL;
> > > > QemuOpts *opts;
> > > > MachineClass *mc;
> > > > const char *optstr = qdict_get_str(qdict, "opts");
> > > > bool node = qdict_get_try_bool(qdict, "node", false);
> > > >
> > > > if (node) {
> > > > hmp_drive_add_node(mon, optstr);
> > > > return;
> > > > }
> > > >
> > > > opts = drive_def(optstr);
> > > > if (!opts)
> > > > return;
> > > >
> > > >
> > > > hmp_drive_add_node() uses error_report() and error_report_err(). Easy
> > > > enough to fix if you move the function here, as I suggested in my review
> > > > of PATCH 8.
> > >
> > > To be honest that involves exporting the monitor_bdrv_states variable and
> > > bds_tree_init, which were both static before, but I created a patch that does that,
> > > If that is all right, I'll squash it with some of my patches.
> > >
> > >
> > > >
> > > > drive_def() is a wrapper around qemu_opts_parse_noisily(), which uses
> > > > error_report_err(). You can't change qemu_opts_parse_noisily() to use
> > > > hmp_handle_error(). You'd have to convert drive_def() to Error, which
> > > > involves switching it to qemu_opts_parse() + qemu_opts_print_help().
> > > >
> > > > These are just the first two error paths in this file. There's much
> > > > more. Truly routing all HMP errors through hmp_handle_error() takes a
> > > > *massive* Error conversion effort, with a high risk of missing Error
> > > > conversions, followed by a never-ending risk of non-Error stuff creeping
> > > > in.
> > >
> > > Oops. Active can of worms is detected. Take cover!
> >
> > :)
> >
> > > > There must be an easier way.
> > > >
> > > > Consider vreport():
> > > >
> > > > switch (type) {
> > > > case REPORT_TYPE_ERROR:
> > > > break;
> > > > case REPORT_TYPE_WARNING:
> > > > error_printf("warning: ");
> > > > break;
> > > > case REPORT_TYPE_INFO:
> > > > error_printf("info: ");
> > > > break;
> > > > }
> > > >
> > > > Adding the prefix here (either unconditionally, or if cur_mon) covers
> > > > all HMP errors reported with error_report() & friends in one blow.
> > >
> > > This is a very good idea.
> > > If feels like this should be done unconditionally, although that will
> > > break probably some scripts that depend on exact value of the error message (but to be honest,
> > > scripts shouldn't be doing that in first place).
> > >
> > > Doing that with cur_mon (took me some time to figure out what that is) will
> > > limit the damage but its a bit of a hack.
> > >
> > >
> > > I think that this is a very good change anyway though so if everyone agrees,
> > > I will be more that happy to do this change.
> > > Thoughts?
> >
> > I think adding an "error: " tag has been proposed before.
> >
> > I dislike overly decorated error messages, because decoration tends to
> > obscure information.
> >
> > However, when there's significant non-error output, or even uncertainty
> > of what's an error and what's something else, decoration can help.
> Yes, also this way it is consistent
Yes I also like it; I wouldn't worry too much about things parsing error
messages for the exact error message; if anything is doing that then the
corresponding case needs to have big red flags around it.
Dave
> >
> > Perhaps you can give some examples where the proposed decoration helps.
> It helps to tag most monitor messages with error prefix which was the root cause of
> me starting to work on this refactoring.
> You suggested this, and I kind of like that idea.
>
> >
> > > > That leaves the ones that are still reported with monitor_printf().
> > > > Converting those to error_report() looks far more tractable to me.
> > >
> > > Yep, in fact I grepped the tree for monitor_printf and there are not
> > > that much instances of this used for error reporting, so it might
> > > be possible to have 'error' prefix on all monitor errors that way
> > > and not only for the block layer.
> >
> > I figure "all" would be more useful than "just for the block layer".
> Yep, the cover letter is outdated, now this patch series touch way
> more that the block layer.
>
> Best regards,
> Maxim Levitsky
>
>
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2020-01-28 19:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-20 18:58 [PATCH 0/9] RFC: [for 5.0]: HMP monitor handlers cleanups Maxim Levitsky
2019-11-20 18:58 ` [PATCH 1/9] monitor: uninline add_init_drive Maxim Levitsky
2019-11-27 7:13 ` Markus Armbruster
2020-01-27 11:03 ` Maxim Levitsky
2019-11-20 18:58 ` [PATCH 2/9] monitor: rename device-hotplug.c to blockdev-hmp-cmds.c Maxim Levitsky
2019-11-20 18:58 ` [PATCH 3/9] monitor: move hmp_drive_del and hmp_commit " Maxim Levitsky
2019-11-27 7:29 ` Markus Armbruster
2020-01-27 11:03 ` Maxim Levitsky
2019-11-27 7:50 ` Markus Armbruster
2020-01-27 11:03 ` Maxim Levitsky
2019-11-20 18:58 ` [PATCH 4/9] monitor: move hmp_drive_mirror and hmp_drive_backup " Maxim Levitsky
2019-11-27 7:22 ` Markus Armbruster
2020-01-27 11:04 ` Maxim Levitsky
2019-11-20 18:58 ` [PATCH 5/9] monitor: move hmp_block_job* to blockdev-hmp-cmd.c Maxim Levitsky
2019-11-27 7:24 ` Markus Armbruster
2020-01-27 11:03 ` Maxim Levitsky
2019-11-20 18:58 ` [PATCH 6/9] monitor: move hmp_snapshot_* to blockdev-hmp-cmds.c Maxim Levitsky
2019-11-20 18:58 ` [PATCH 7/9] monitor: move remaining hmp_block* functions " Maxim Levitsky
2019-11-20 18:58 ` [PATCH 8/9] monitor: move hmp_info_block* " Maxim Levitsky
2019-11-27 8:08 ` Markus Armbruster
2020-01-27 11:05 ` Maxim Levitsky
2020-01-27 13:33 ` Markus Armbruster
2020-01-27 13:54 ` Maxim Levitsky
2020-01-27 14:07 ` Kevin Wolf
2019-11-20 18:58 ` [PATCH 9/9] monitor/hmp: Prefer to use hmp_handle_error for error reporting in block hmp commands Maxim Levitsky
2019-11-27 8:38 ` Markus Armbruster
2020-01-27 11:04 ` Maxim Levitsky
2020-01-27 13:44 ` Markus Armbruster
2020-01-27 13:53 ` Maxim Levitsky
2020-01-28 19:35 ` Dr. David Alan Gilbert [this message]
2019-11-22 10:15 ` [PATCH 0/9] RFC: [for 5.0]: HMP monitor handlers cleanups Dr. David Alan Gilbert
2019-11-22 10:27 ` 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=20200128193534.GG3215@work-vm \
--to=dgilbert@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=mlevitsk@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.