[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:1.9.2.14) 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
qmp.eject_device(device='ide0-hd0')
But I cannot write a library today that does:
qmp.eject_device('ide0-hd0')
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.
Regards,
Anthony Liguori
- [Qemu-devel] [PATCH 12/15] qapi: add QMP put-event command, (continued)
Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2), Anthony Liguori, 2011/03/16
- Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2), Luiz Capitulino, 2011/03/16
- Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2),
Anthony Liguori <=
- Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2), Luiz Capitulino, 2011/03/16
- Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2), Anthony Liguori, 2011/03/16
- Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2), Luiz Capitulino, 2011/03/18
- Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2), Anthony Liguori, 2011/03/18
Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2), Kevin Wolf, 2011/03/17
Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2), Anthony Liguori, 2011/03/17
Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2), Kevin Wolf, 2011/03/17
Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2), Anthony Liguori, 2011/03/17
Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2), Kevin Wolf, 2011/03/17
Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2), Anthony Liguori, 2011/03/17