From: Luiz Capitulino <lcapitulino@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: pbonzini@redhat.com, Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 5/8] qemu-img: img_create(): use Error object
Date: Tue, 23 Oct 2012 11:07:09 -0200 [thread overview]
Message-ID: <20121023110709.345638b5@doriath.home> (raw)
In-Reply-To: <50866CB8.7060304@redhat.com>
On Tue, 23 Oct 2012 12:08:56 +0200
Kevin Wolf <kwolf@redhat.com> wrote:
> >> qemu-img doesn't have an HMP monitor, so it doesn't hurt either. If you
> >> want to replace it, replace it with a copy of qemu-error.c that only
> >> removes the monitor_vprintf() case. That is, in particular, leave all of
> >> the loc_*() functionality there, because this is something that is meant
> >> for use in command line parsers.
> >
> > Strongly agreed on use of error_report(). Buys us uniform error
> > messages that can point to the location causing the error. The fact
> > that error_report() does the right thing in monitor context is detail.
> >
> > I don't see why purging a few monitor references from tools is worth
> > copying the file. Stubbing out cur_mon and monitor_vprintf() in tools
> > is just fine, in my opinion.
>
> Purging monitor references from the code isn't worth it.
It depends. Basically, any function that does any version of:
if (qmp) {
/* do qmp stuff */
} else if (hmp) {
/* do hmp stuff */
} else if (command-line) {
/* do cmd-line stuff */
}
Is very likely wrong, as it's mixing three different layers. The problem
this gives ranges from a bloated function to errors not getting correctly
reported or a change in "do hmp stuff" affects qmp or any other layer in
the mix.
Of course that it's completely fine for a function to be called from more than
one layer, but it has to be generic enough so that it doesn't make assumptions
wrt the context it's being used.
Of course that we don't have to fix everything right now, and a few places
can make minimal use of such functions in way that it will never hurt.
But at a minimum we shouldn't add more of these.
> Becoming
> independent from functions also used by the monitor, which keep being
> subject of heated discussions, might be worth it, because I don't feel
> like joining these discussions more often than absolutely necessary.
>
> It was just my offer in case Luiz insists on getting rid of
> error_report() in the tools, not something I'd advocate myself.
>
> Kevin
>
next prev parent reply other threads:[~2012-10-23 13:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-17 19:35 [Qemu-devel] [PATCH 0/8] block: bdrv_img_create(): propagate errors Luiz Capitulino
2012-10-17 19:35 ` [Qemu-devel] [PATCH 1/8] error: add error_set_errno and error_setg_errno Luiz Capitulino
2012-10-17 19:35 ` [Qemu-devel] [PATCH 2/8] block: bdrv_img_create(): add param_list argument Luiz Capitulino
2012-10-18 11:57 ` Kevin Wolf
2012-10-18 13:33 ` Luiz Capitulino
2012-10-18 17:18 ` Luiz Capitulino
2012-10-19 9:13 ` Kevin Wolf
2012-10-19 12:49 ` Luiz Capitulino
2012-10-17 19:35 ` [Qemu-devel] [PATCH 3/8] block: bdrv_img_create(): move parameter list printing to qemu-img Luiz Capitulino
2012-10-18 12:01 ` Kevin Wolf
2012-10-18 12:16 ` Kevin Wolf
2012-10-18 13:34 ` Luiz Capitulino
2012-10-17 19:35 ` [Qemu-devel] [PATCH 4/8] block: bdrv_img_create(): add Error ** argument Luiz Capitulino
2012-10-18 12:08 ` Kevin Wolf
2012-10-18 13:41 ` Luiz Capitulino
2012-10-17 19:35 ` [Qemu-devel] [PATCH 5/8] qemu-img: img_create(): use Error object Luiz Capitulino
2012-10-18 12:11 ` Kevin Wolf
2012-10-18 13:49 ` Luiz Capitulino
2012-10-18 14:02 ` Kevin Wolf
2012-10-23 9:58 ` Markus Armbruster
2012-10-23 10:08 ` Kevin Wolf
2012-10-23 13:07 ` Luiz Capitulino [this message]
2012-10-17 19:35 ` [Qemu-devel] [PATCH 6/8] qemu-img: img_create(): simplify Luiz Capitulino
2012-10-17 19:35 ` [Qemu-devel] [PATCH 7/8] qmp: qmp_transaction(): pass Error object to bdrv_img_create() Luiz Capitulino
2012-10-17 19:35 ` [Qemu-devel] [PATCH 8/8] block: bdrv_img_create(): drop unused error handling code Luiz Capitulino
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=20121023110709.345638b5@doriath.home \
--to=lcapitulino@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--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).