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

[Daniel P. Berrange]

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 - 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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|