On Fri, 27 Aug 2010 14:37:54 -0500 Anthony Liguori <anth...@codemonkey.ws> wrote:
> 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. ... And as a QMP client I don't see the point in having to use a new command just because a new argument was needed. The language QEMU is written is also unimportant. The wire format is all I see and it's language independent. > 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. Why? I mean, what would stop us on extending QMP when the C interface is also extended? Examples? At first, this seems a good middle ground to me: QMP is implemented on top of the C API and the JSON stuff is limited to QMP. Of course that C API functions returning structured data will have to create and return qobjects. But that's needed even with the direct mapping. > 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. I agree, I just think an indirect mapping would be more beneficial to QMP clients.