[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 15:00:10 -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 02:27 PM, Luiz Capitulino wrote:

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.
I mentioned bindings because you put so much emphasis on C consumers
that sometimes I wonder if all you want is libqmp and libqmp only.

The transports (libqmp and QMP) are less important than the interface itself. My emphasis is on the API, not the transports or materialization of it.

The terminology gets confusing and I probably am not consistent enough in how I use it.

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.
I'm sorry? Critical mistake? Didn't _we_ consciously choose a dictionary
for this?

Yes, we did. In fact, I'm fairly sure that Avi and/or I strongly advocated it.

But hindsight is always 20/20 and if our goal is to have an API that doesn't require special support in Python beyond a simple transport class, using dictionaries and not allowing unnamed positional parameters was a mistake.

But we makes lots of mistakes.  That's part of the development process.

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.
I don't get it. Having knowledge of the schema is needed anyway, isn't it?

If we allowed positional arguments, it wouldn't be needed. For instance, with xmlrpclib in python, you can do:

srv = ServerProxy('http://localhost:8000/RPC2')

And it Just Works. The transport doesn't have to know anything about the schema because the server does all of the parameter validation.

We could fix this by adding another way of specifying unnamed parameters in QMP. Something like:

import qmp

srv = qmp.ServerProxy('/tmp/qmp.sock')


{ 'execute': 'eject_device', 'ordered_arguments': [ 'ide0-hd0' ], arguments: {} }

I'm not sure it's really worth it though. I don't think it's a terrible thing for us to generate a Python consumable schema. I don't think it's all that important for us to worry about QMP as an RPC mechanism being consumable outside of QEMU which means that we can (and should) be providing high level language libraries for it.

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
Does this suggest you think libvirt should switch from QMP to libqmp?

I think they eventually should, yes. Why duplicate all of the marshalling and unmarshalling code unnecessarily especially when dealing with complex data structures?

And, if you don't want to focus on non-C consumers, why having QMP at all?
(I'm *not* saying I'm ok in dropping it).

No matter what, we need an RPC. You can't drop QMP because something needs to take it's place.

The question is whether we expect projects to write directly to the protocol or use libraries provided by use to handle it. I don't think it's practical to expect everyone to write directly to the protocol (particularly when dealing with C).

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 :-)
This comment assumes two things: 1. query-pci is good in its current form,

I think it's one of our better commands actually.

2. libvirt doesn't use it because it's complex.

We already had changes proposal to query-pci and I can't tell why libvirt
doesn't use it. If it's because it's complex, then we need to know why it's
complex: is it the command or is it accessing JSON from C?

It returns a complex data structure. There's nothing wrong with that, but it's very hard to interface with at the JSON level. Is there really any doubt about that?

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.
We'll be eating our food just fine by using the internal interface
as an internal interface.

What I struggle with it what it means for you to say that libqmp is an internal interface. libqmp is a C library that implements QMP. QEMU would never use libqmp directly (it doesn't need to). If it cannot maintain a stable ABI, than that means it's impossible to write a QMP client that maintains a stable C ABI unless you totally redefine the interfaces.

Is that really desirable?


Anthony Liguori


Anthony Liguori

reply via email to

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