KVM call minutes for November 29

KVM call minutes for November 29

[Juan Quintela]

Plans for 1.0
- rc4 should be the last release
- should ship 1.0 on Thrusday

Merge window start on Monday

How to handle stable tree, getting a stable team?
- Justin: he don't do schedules for releases because it depends on when patches arrive.
- Adding a list for stable patches instead of more maintainers?

Next release?
- 6 month long also?  Anthony: discuss it next week
  * think about it, and do proposals for next week call

Update on QOM
- Dynamic propierties for qdev
- change types on qdev without touching all the tree several times

Test infraestructure
- Using a mini-os as an external process to be able to use libc and things like that.

Sandboxing and other languages
- sandboxing difficult
- embedding a language (python?), that would make doing the easy
  devices emulation really easy

How to do high level stuff?
- python?

Maintainer not responsive:
- MIPS as an example, what to do.
- In the specific case of MIPS, we haven't had a maintaner since Thiemo
- If you feel that a subsystem is not being maintained, just make
  noise on the list

See you next week.

[Qemu-devel] KVM call minutes for November 29

[Juan Quintela]

Plans for 1.0
- rc4 should be the last release
- should ship 1.0 on Thrusday

Merge window start on Monday

How to handle stable tree, getting a stable team?
- Justin: he don't do schedules for releases because it depends on when patches arrive.
- Adding a list for stable patches instead of more maintainers?

Next release?
- 6 month long also?  Anthony: discuss it next week
  * think about it, and do proposals for next week call

Update on QOM
- Dynamic propierties for qdev
- change types on qdev without touching all the tree several times

Test infraestructure
- Using a mini-os as an external process to be able to use libc and things like that.

Sandboxing and other languages
- sandboxing difficult
- embedding a language (python?), that would make doing the easy
  devices emulation really easy

How to do high level stuff?
- python?

Maintainer not responsive:
- MIPS as an example, what to do.
- In the specific case of MIPS, we haven't had a maintaner since Thiemo
- If you feel that a subsystem is not being maintained, just make
  noise on the list

See you next week.

Re: KVM call minutes for November 29

[Avi Kivity]

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.

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

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.

-- 
error compiling committee.c: too many arguments to function

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

[Markus Armbruster]

Avi Kivity <avi@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.

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

[Markus Armbruster]

Avi Kivity <avi@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.

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

[Anthony Liguori]

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.
>

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

[Anthony Liguori]

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.
>

Re: KVM call minutes for November 29

[Juan Quintela]

Markus Armbruster <armbru@redhat.com> wrote:
> Avi Kivity <avi@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.

ocaml (Standard ML is a big monster) is not inmature.  But depending on
how much we want to implement on it, its integral types are not very
good.

- no unsigned types
- signed types are 31 and 63 bits wide, sniff.

And its object system is ...... bizarre?
On the other side, inference is quite understable, and its type
inference works pretty well.  And doing stubs with * is tedious, but not
difficult at all.

Later, Juan.

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

[Juan Quintela]

Markus Armbruster <armbru@redhat.com> wrote:
> Avi Kivity <avi@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.

ocaml (Standard ML is a big monster) is not inmature.  But depending on
how much we want to implement on it, its integral types are not very
good.

- no unsigned types
- signed types are 31 and 63 bits wide, sniff.

And its object system is ...... bizarre?
On the other side, inference is quite understable, and its type
inference works pretty well.  And doing stubs with * is tedious, but not
difficult at all.

Later, Juan.

Re: KVM call minutes for November 29

[Alon Levy]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alon Levy]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 :|

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

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

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

[Alon Levy]

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]

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

[Alon Levy]

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]

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

[Anthony Liguori]

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]
>

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

[Avi Kivity]

On 11/29/2011 09:10 PM, Markus Armbruster wrote:
> Avi Kivity <avi@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

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

[Avi Kivity]

On 11/29/2011 09:10 PM, Markus Armbruster wrote:
> Avi Kivity <avi@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