Re: [Qemu-devel] QOM vs QAPI for QMP APIs

[Kevin Wolf <kwolf@redhat.com>]

Am 21.02.2014 um 15:32 hat Stefan Hajnoczi geschrieben:
> On Fri, Feb 21, 2014 at 10:16 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > Maybe I just need some convincing but it seems that QAPI is the simplest
> > and cleanest way to define external APIs.
> >
> > Disagree?  Tell me why :).
> 
> I'm replying to myself because we had an interesting discussion on
> IRC.  Thanks Paolo, Markus, and Peter!
> 
> I'm biased, but here are the points collected from the discussion:
> 
> Why QOM *should* be QEMU's external API:
>  * QOM eliminates hand-written QMP API code.  We get query-foo APIs
> for free using qom-list, qom-get, qom-set, and friends

I don't think this is valid point. We already have a QAPI code
generator. There's no reason why it couldn't automatically map things to
QOM for certain commands.

This means that you would internally use QOM in order to get rid of
hand-written code, but it would be an implementation detail and the
external API would still be as high-level as it is today.

> Why QOM should *not* be QEMU's external API:
>  * Internal objects will diverge from the external QOM objects over
> time, we'll have to maintain a backwards compatible QOM object layer
> on top of QEMU's internal objects - that defeats the whole point of
> getting APIs for free from QOM

This is a very important point. We already managed to mess up existing
QMP commands so that we're jumping through hoops to provide an old
interface, which doesn't really match the design we want to have.
Sometimes it prevents us from making changes.

With QOM, we potentially expose everything, every little detail of our
internal implementation. If we don't say that there is no (or at least
very weak) compatibility promise, then we're forever stuck with whatever
broken design we first came up with.

If QOM comes with stability requirements, I'll veto any conversion patch
of any part of the block layer to QOM.

>  * We lose the easy-to-review qapi-schema.json.  Would need new
> documentation and review tools for QOM model changes.
>  * query-foo APIs are simple to implement, not a huge win to get them via QOM
>  * QAPI is mature and well-understood, QMP is incomplete
>  * qom-list, qom-get, qom-set are too low-level, need more powerful
> APIs to save clients from elaborate back-and-forth conversations

Right, QOM is simple in the way that programming in assembly is simple.
The building blocks are really simple and easy to explain, but building
something higher level from it is hard and easy to get wrong.

Try expressing a 'transaction' QMP command with multiple newly created
snapshots and a backup job in QOM... (without creating a transaction
object that contains the current QAPI arguments as properties, because
that wouldn't really be using QOM but tunneling QMP through QOM)

External QOM interfaces have their place, especially for debugging or
trying out things before there is a proper API, but it's not as the
primary external interface.

Kevin