[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v

From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2)
Date: Wed, 16 Mar 2011 13:32:50 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

On 03/16/2011 01:09 PM, Luiz Capitulino wrote:
This is a shift in our direction but the good news is that the practical
impact is small.  But I don't think there's a lot of value of focusing
on non-C consumers because any non-C consumer is capable of consuming a
good C interface (but the inverse is not true).
I disagree. To access a C interface from a high-level language you usually
have to write bindings. Using something like QMP instead of writing bindings
is a lot easier.

I think you're confusing multiple points.

A C friendly interface has the following properties:

1) arguments have a well defined order
2) variant arrays are not used
3) variant types are not used
4) structures only have items added to the end of them with some sort of way to determine at run time whether the argument is present
5) functions don't increase their number of arguments

An API that follows these rules is a Good Library interface in C. It also happens to be a Good Library interface in Python and just about every other language.

You can design interfaces in Python that rely on variant arrays or types, or that add keyword values to arguments, but the absence of those does not make a Bad Library in Python.

This has nothing to do with the need for bindings. The need for bindings is entirely based on whether the RPC being used is self-describing. JSON is.

That said, I think we made a critical mistake in QMP that practically means that we need bindings for QMP. There is no argument ordering. So I can write a Python class that does:

import qmp


But I cannot write a library today that does:


Without using a library that has knowledge of the QMP schema. This is somewhat unfortunate and I've been thinking about adding another code generation mode in qmp-gen.py to generate wrappers that would enable the more natural usage in Python.

Also, what's the problem with C consumers using QMP? Libvirt is C, and it
does it just fine.

I was going to cut and paste libvirt's code that handles query-pci to show you how complex it is to use vs. just using libqmp but it turns out libvirt doesn't implement query-pci in QMP mode and falls back to the human monitor. I think that might be as good of a way to show my point though :-)

But the same sort of compatibility considerations apply to using QMP
within QEMU.  If you add a new field to a function call, we need to
modify any internal usage of the API.
What's the problem of doing this?

If we have a bunch of code in QEMU that relies on doing

qmp_set_vnc_password(password, &err);

And then we add a new parameter to set_vnc_password(), we now need to touch ever place we call this.

Good external interfaces also happen to be good internal interfaces and encourage better modularity within QEMU itself. It also means that for subsystems that we can convert to be largely implemented in terms of QMP, we have the option to move them into an external process which is good from a security PoV.

If we add a field to a structure,
as long as we use feature flags (we do), only the places that care to
set that field need to worry about it.
Why do we need this in an internal interface?

It's about eating our own dog food. It helps us ensure that we're really providing high quality external interfaces.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]