On 08/27/2010 02:24 PM, Luiz Capitulino wrote:
I don't see how 0.13.0 is going to get releases with anything but the
current behavior. It's unfortunate but we're too delayed and can't
afford a change like this this late in the game.
In terms of the stable branch, the least disruptive thing would be a
timeout.
Okay.
I think we have agreed on the internal interfaces approach. My only
concern is whether this will conflict when extending the wire protocol
(eg. adding new arguments to existing commands). Not a problem if the
C API is not stable, of course.
We don't do that. It's a recipe for disaster. QEMU isn't written in
Python and if we try to module our interfaces are if we were a Python
library, we're destined to fail.
You mean we don't do simple protocol extensions?
So, if we need an new argument to an existing command, we add a new
command instead? Just because QEMU is not written in Python?
Because it's too easy to get it wrong in QEMU. Here's the rationale.
If I can't trivially call a QMP function in C, then I'm not going to use
QMP functions within QEMU. I'm not going to create an embedded JSON
string just to call a function with three integer arguments.
Yes, if we need to do that, we can create a C API that both the QMP
interface uses and we also use internally but why? All that does is
introduce the chance that the C API will have more features than the QMP
interface.
If we don't use these functions in QEMU, then how do we know that these
functions have reasonable semantics? This is exactly the problem we
suffer today. We have internal APIs that do reasonable things but
everything that deals with QMP is a special case. That creates too many
opportunities to get things wrong.
I think it's a vitally important requirement that all future QMP
functions have direct mappings to a C interface. The long term goal
should be for that interface to be used by all of the command line
arguments, SDL, and the human monitor. If those things only relied on a
single API and we exposed that API via QMP, than we would have an
extremely useful interface.
Regards,
Anthony Liguori
