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
