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

[Anthony Liguori]

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