qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 5/8] qemu-img: img_create(): use Error object


From: Luiz Capitulino
Subject: Re: [Qemu-devel] [PATCH 5/8] qemu-img: img_create(): use Error object
Date: Tue, 23 Oct 2012 11:07:09 -0200

On Tue, 23 Oct 2012 12:08:56 +0200
Kevin Wolf <address@hidden> 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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]