Re: [Qemu-devel] [RFC 0/5] Monitor handlers convertion to QObject

[Luiz Capitulino <lcapitulino@redhat.com>]

On Thu, 03 Sep 2009 22:30:08 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:

>    Hi,
> 
> >   Some people have suggested us to define errors codes, but I dislike this
> > because I have the impression we will end up defining errors per-handlers,
> > which is a lot of work and more protocol definitions to maintain.
> 
> What about error messages?

 Yes, I had error messages in mind.

 Handlers that handle errors today already print error messages,
this way the additional effort would be with the ones which don't
handle errors.

 However, my initial argument is not very strong. We already have
per-handlers errors today and will also have them with strings.

> I've recently added some infrastructure for error messages: 
> qemu_error() + friends.  Intention is to direct error messages to the 
> correct place, especially for code which can be called from multiple 
> paths.  Device creation for example can be triggered by command line 
> (errors should go to stderr) or via hotplug monitor commands (errors 
> should go to the monitor).
> 
> You might want to add a third error sink which stuffs error messages 
> into a Qstring, so you can pass them along as Qobject without the code 
> emitting the error message knowing anything about it.

 Ok, I will review qemu_error() and consider your suggestion.

> 
> >   Another issue in this subject is that sometimes we will have to do
> > a not so small refactor to get the proper error code. I mean, sometimes
> > the functions which the handlers call return void, and those functions in
> > turn call other functions which also return void. This seem to be the
> > case of do_balloon(), for example.
> 
> There are also a few places which call exit(1) on error.  Which is ok 
> when something goes wrong while creating the virtual machine, but not 
> when some monitor command failed ...

 Right.

> 
> >   A possible solution is to only return error when it's easy, otherwise we
> > could always return 0 (which is what we have today), the problem though
> > is that changing this in the future will cause trouble.
> 
> Serious code audit is more work initially, but I think we well be very 
> happy we did it in the long run ...

 That's right.

 I'm doing my best to have the protocol working ASAP, but it's
unfortunate that sometimes the Right Thing takes more time.