qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v0 00/21]: Monitor: improve handlers error handl


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v0 00/21]: Monitor: improve handlers error handling
Date: Thu, 11 Feb 2010 11:17:42 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 02/11/2010 10:57 AM, Markus Armbruster wrote:
Yes, that's a sensible argument.  It's also quite impractical at this
time.  In fact, I had the same idea, and dropped it like a hot potato
when I realized how much code we'd have to touch for it.

Can you give me an example of where it gets particularly ugly? It doesn't look so bad to me.

Because besides the single call chain func3(), func2(), func1(), there
are many more, and large parts of them never heard of the monitor or
qerror/qobject.  There are places that happily ignore errors (and
nevertheless work tolerably well), and they all become memory leaks if
we change the error value from int to qobject.

Look, we're sitting in a nice hole with QMP right now.  We set ambitious
goals, we've been working on it for months, and we got quite some code,
but the result is still not useful.  It really needs to become useful as
soon as possible.

Once we made it out of this hole, I'll be game for refactoring stuff to
make it more flexible and less ugly.  But as long as I'm sitting in this
hole, I'd prefer not to dig deeper.

Yeah, I can accept this argument provided that we're all in agreement for where we're going long term. I'd still like to understand the pragmatic issue that we're facing right now though.

Regards,

Anthony Liguori

The current qerror stuff is really only useful within a single
function.  Once you start building infrastructure around qerror, it
becomes very difficult to deal with.
[...]





reply via email to

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