Re: [Qemu-devel] KVM call minutes for November 29
On 11/29/2011 09:10 PM, Markus Armbruster wrote: Avi Kivity a...@redhat.com writes: 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. On the other hand, the statically typed languages usually have more boilerplate. Since one of the goals is to simplify things, this indicates the need for a language with type inference. On the third hand, languages with type inferences are still immature (golang?), so we probably need to keep this discussion going until an obvious choice presents itself. I wouldn't call ML immature. But I wouldn't call it a scripting language, either. It was just off the radar for me. We should consider it, by all means. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for November 29
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). 2) We could then add a binding layer to let python code implement a character device. 3) We could implement the HMP logic in Python. 4) We could add a GTK widget to replace the SDL displaystate and then use python code to implement a more friendly UI. Most of the interaction with such an interface would probably go through (1). With clever coding, you could probably let the UI also be stand alone using GtkVnc in place of the builtin widget and using a remote interface for QMP. Regards, Anthony Liguori On the other hand, the statically typed languages usually have more boilerplate. Since one of the goals is to simplify things, this indicates the need for a language with type inference. On the third hand, languages with type inferences are still immature (golang?), so we probably need to keep this discussion going until an obvious choice presents itself. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for November 29
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 :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for November 29
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for November 29
On Wed, Nov 30, 2011 at 07:54:30AM -0600, Anthony Liguori wrote: [snip] But the way we're structuring QOM, we could do very simple bindings that just used introspection (much like GObject does). Is this the current tree? http://repo.or.cz/w/qemu/aliguori.git/tree/refs/heads/qom The vast majority of work is fitting everything into an object model. Doing the bindings is actually fairly simple. Regards, Anthony Liguori [snip] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for November 29
On 11/30/2011 08:35 AM, Alon Levy wrote: On Wed, Nov 30, 2011 at 07:54:30AM -0600, Anthony Liguori wrote: [snip] But the way we're structuring QOM, we could do very simple bindings that just used introspection (much like GObject does). Is this the current tree? http://repo.or.cz/w/qemu/aliguori.git/tree/refs/heads/qom That's the end goal, more or less. The current submission tree is: https://github.com/aliguori/qemu/tree/qom-upstream.4 I just need to rebase and send those out. Regards, Anthony Liguroi The vast majority of work is fitting everything into an object model. Doing the bindings is actually fairly simple. Regards, Anthony Liguori [snip] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for November 29
Avi Kivity a...@redhat.com writes: 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. On the other hand, the statically typed languages usually have more boilerplate. Since one of the goals is to simplify things, this indicates the need for a language with type inference. On the third hand, languages with type inferences are still immature (golang?), so we probably need to keep this discussion going until an obvious choice presents itself. I wouldn't call ML immature. But I wouldn't call it a scripting language, either. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for November 29
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. 2) We could then add a binding layer to let python code implement a character device. 3) We could implement the HMP logic in Python. 4) We could add a GTK widget to replace the SDL displaystate and then use python code to implement a more friendly UI. Most of the interaction with such an interface would probably go through (1). With clever coding, you could probably let the UI also be stand alone using GtkVnc in place of the builtin widget and using a remote interface for QMP. Regards, Anthony Liguori On the other hand, the statically typed languages usually have more boilerplate. Since one of the goals is to simplify things, this indicates the need for a language with type inference. On the third hand, languages with type inferences are still immature (golang?), so we probably need to keep this discussion going until an obvious choice presents itself. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
