From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.com>
Cc: Developers qemu-devel <qemu-devel@nongnu.org>,
KVM devel mailing list <kvm@vger.kernel.org>,
quintela@redhat.com
Subject: Re: [Qemu-devel] KVM call minutes for November 29
Date: Tue, 29 Nov 2011 16:59:51 -0600 [thread overview]
Message-ID: <4ED563E7.3040508@codemonkey.ws> (raw)
In-Reply-To: <4ED50F7C.2040903@redhat.com>
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.
>
next prev parent reply other threads:[~2011-11-29 22:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-29 15:51 [Qemu-devel] KVM call minutes for November 29 Juan Quintela
2011-11-29 16:59 ` Avi Kivity
2011-11-29 19:10 ` Markus Armbruster
2011-11-30 1:18 ` Juan Quintela
2011-12-01 9:32 ` Avi Kivity
2011-11-29 22:59 ` Anthony Liguori [this message]
2011-11-30 9:22 ` Alon Levy
2011-11-30 9:54 ` Daniel P. Berrange
2011-11-30 13:54 ` Anthony Liguori
2011-11-30 14:35 ` Alon Levy
2011-11-30 14:38 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ED563E7.3040508@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).