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]

Anthony Liguori <address@hidden> writes:

> On 08/27/2010 02:24 PM, Luiz Capitulino wrote:
[...]
>>>> 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, an internal interface is better done in idiomatic C, not with JSON
strings.

> 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 is that bad?

Internal and external interfaces have very different tradeoffs.

An internal interface should eschew backward compatibility and embrace
change.

An external interface needs to be stable, yet extensible.

It's therefore advisable to separate the two.  Otherwise the internal
interface gets bogged down with undue compatibility considerations
(backward & forward), or the external interface suffers unnecessary
churn.

When we designed QMP, we took special care to make it support compatible
evolution.  We consciously made it a proper protocol, not RPC to
internal C interfaces.  Are you proposing we go back to square one and
reargue the basics of QMP?

> 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.

No, the problem we suffer today is that we didn't design the external
interface properly above the level of basic protocol.  We took a
shortcut and converted existing monitor commands.  We've since
discovered we don't like that approach.

Instead of giving up on protocol design without even trying and just
expose whatever internal interfaces strike us as useful via RPC, let's
design the external interface properly.

> I think it's a vitally important requirement that all future QMP
> functions have direct mappings to a C interface.

Why?

>                                                   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.

Yes, command line, human monitor and QMP should use internal interfaces
to do the real work, thus separate the real work neatly from
interface-specific stuff like parsing text.

No, that doesn't mean we should expose internal interfaces via RPC.