qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 00/14]: Initial QObject conversion


From: Luiz Capitulino
Subject: Re: [Qemu-devel] [PATCH v1 00/14]: Initial QObject conversion
Date: Fri, 2 Oct 2009 10:47:29 -0300

On Fri, 02 Oct 2009 14:47:02 +0200
Gerd Hoffmann <address@hidden> wrote:

>    Hi,
> 
> >   Some people have suggested that we should have a better error handling
> > in the Monitor, in the meaning that error information should be correctly
> > propagated and handled in order to be used by the Monitor Protocol and
> > the existing user protocol.
> 
> A bunch of code paths can be called from both monitor and non-monitor 
> contexts (network configuration, device hotplug).  Right now there are 
> the qemu_error*() functions to make sure the error messages appear on 
> the correct place (monitor or stderr) without having to pass through a 
> Monitor pointer all the way down.
> 
> How do you plan to handle this in the new world of monitor error reporting?

 Good question.

 The first thing to bear in mind is that MonitorError is not just about
error reporting, but more importantly, it makes errors have a common
structure so that they can be emitted by the Monitor Protocol.

 One way to solve the problem could be to move the MonitorError pointer
to the Monitor struct. This way, when there's a ERR_SINK_MONITOR
qemu_error() would fill MonitorError instead of calling monitor_vprintf().

 The bad news though, is that we would have to change all qemu_error()
calls to have "structured" errors instead of pretty printing, that is,
create macros, define its errors data and write functions to do
pretty printing....

 Looks hard, doesn't it?

 The real problem behind all QMP work is that we're starting from
a big amount of human-targeted functionality and trying to make it
common so that it's useful for machines as well.




reply via email to

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