Re: [Qemu-devel] KVM call minutes for November 29

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

 



On 11/30/2011 03:54 AM, Daniel P. Berrange wrote:
On Wed, Nov 30, 2011 at 11:22:37AM +0200, Alon Levy wrote:
On Tue, Nov 29, 2011 at 04:59:51PM -0600, Anthony Liguori wrote:
On 11/29/2011 10:59 AM, Avi Kivity wrote:
On 11/29/2011 05:51 PM, Juan Quintela wrote:
How to do high level stuff?
- python?


One of the disadvantages of the various scripting languages is the lack
of static type checking, which makes it harder to do full sweeps of the
source for API changes, relying on the compiler to catch type (or other)
errors.

This is less interesting to me (figuring out the perfectest language to use).

I think what's more interesting is the practical execution of
something like this.  Just assuming we used python (since that's
what I know best), I think we could do something like this:

1) We could write a binding layer to expose the QMP interface as a
python module.  This would be very little binding code but would
bring a bunch of functionality to python bits.

If going this route, I would propose to use gobject-introspection [1]
instead of directly binding to python. You should be able to get
multiple languages support this way, including python. I think it
requires using glib 3.0, but I haven't tested it myself (yet). Maybe
someone more knowledgable can shoot it down.

[1] http://live.gnome.org/GObjectIntrospection/

Actually this might make sense for the whole of QEMU. I think for a
defined interface like QMP implementing the interface directly in python
makes more sense. But having qemu itself GObject'ified and scriptable
is cool. It would also lend it self to 4) without going through 2), but
also make 2) possible (with any language, not just python).

I think taking advantage of GObject introspection is fine idea

GObject isn't flexible enough for our needs within the device model unfortunately.

The main problem is GObject properties. They are tied to the class and only support types with copy semantics. We need object based properties and full builder semantics for accessors.

But the way we're structuring QOM, we could do very simple bindings that just used introspection (much like GObject does).

The vast majority of work is fitting everything into an object model. Doing the bindings is actually fairly simple.

Regards,

Anthony Liguori

 - I
certainly don't want to manually create python (or any other language)
bindings for any C code ever again. GObject + introspection takes away
all the burden of supporting access to C code from non-C languages.
Given that QEMU has already adopted GLib as mandatory infrastructure,
going down the GObject route seems like a very natural fit/direction
to take.

If people like the idea of a higher level language for QEMU, but are
concerned about performance / overhead of embedding a scripting
language in QEMU, then GObject introspection opens the possibilty of
writing in Vala, which is a higher level language which compiles
straight down to machine code like C does.

Regards,
Daniel

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux