[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED er
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message |
Date: |
Fri, 27 Aug 2010 17:58:57 -0300 |
On Fri, 27 Aug 2010 14:37:54 -0500
Anthony Liguori <address@hidden> 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.
- [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, (continued)
- [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Daniel P. Berrange, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Markus Armbruster, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Luiz Capitulino, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Anthony Liguori, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Daniel P. Berrange, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Anthony Liguori, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Luiz Capitulino, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Anthony Liguori, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Luiz Capitulino, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Anthony Liguori, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message,
Luiz Capitulino <=
- Should QMP be RPC to internal C interfaces? (was: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message), Markus Armbruster, 2010/08/30
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Anthony Liguori, 2010/08/30
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Anthony Liguori, 2010/08/30
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Luiz Capitulino, 2010/08/30
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Anthony Liguori, 2010/08/30
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Markus Armbruster, 2010/08/31
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Luiz Capitulino, 2010/08/31
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Anthony Liguori, 2010/08/31
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Markus Armbruster, 2010/08/31
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Anthony Liguori, 2010/08/31