[Qemu-devel] Re: Should QMP be RPC to internal C interfaces?

[Anthony Liguori]

On 08/30/2010 09:52 AM, Markus Armbruster wrote:
> > 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.
>    

Nope.

The internal interface should be the external interface.

Otherwise, the external interface is going to rot.

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

All the pretty JSON interfaces don't matter if we're not exposing a 
useful API.

We're trying to do too much.  We've been more or less completing 
ignoring the problem of creating a useful API for users to consume.

We need to simplify.  We simplify by reducing scope.  Of the things that 
are important, a useful API is more important than whether it maps to 
your favorite dynamic language in an elegant way.

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

What does that even mean?  How do you describe the external interface 
properly?

It's a hell of a lot simpler to design the external interface as a C 
API, and then to implement the external interface as a C API.  Why make 
life harder than that?

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

So that we can consume those APIs within QEMU.

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

Having two interfaces guarantees failure.  What's the separation between 
internal and external?  Is qdev internal or external?

Regards,

Anthony Liguori