From: Fabrice Bellard <fabrice@bellard.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Just a thought (high level API)
Date: Thu, 10 Feb 2005 20:59:29 +0100 [thread overview]
Message-ID: <420BBD21.2070705@bellard.org> (raw)
In-Reply-To: <1107961744.8824.7.camel@localhost.localdomain>
Nathaniel McCallum wrote:
> I know a lot of people are wanting to build qemu frontends and embedding
> the sdl window has been a frustration to several. Well, I was just
> thinking today, what if we moved most of the emulation code behind a
> high level api, creating "libqemu" which would allow for lots of things
> including multiple frontends, embeded qemu, etc. I brainstormed up a
> *very* raw idea yesterday between my classes while taking a very cursory
> glance at the code. I had three goals:
> 1. Create a library (duh!)
> 2. Allow for multiple rendering options (SDL, GTK, QT, win32, etc)
> 3. Allow for storable virtual machine profiles which could be shared
> across all front ends (ie. a virtual machine profile could be used in
> QemuX, a Win32 frontend, a GTK frontend, etc...)
>
> Attached below is a header containing a first crack at a libqemu api.
Such a high level API is a good idea and I plan to add one, but it is
not my priority right now. It is not a necessary condition to have
multiple GUIs or support for configuration files. Moreover, I don't want
the GUI to be an external project for QEMU - the GUI is an integral part
of a program, and I prefer to have one finished GUI than 5 half finished
ones :-)
As a summary I prefer first to have a GUI and then to make some clean up
to support it. The reverse approach often leads to "overdesign" i.e.
bloated code.
Just another point as it was mentionned in the thread: I agree that some
kind of dynamic modules are needed in QEMU - they will come someday. At
the current point I am relunctant to add them to avoid fragmenting the
project and to have to ensure binary compatibility: QEMU is not mature
enough yet.
Fabrice.
next prev parent reply other threads:[~2005-02-10 20:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-09 15:09 [Qemu-devel] Just a thought (high level API) Nathaniel McCallum
2005-02-09 15:52 ` McMullan, Jason
2005-02-10 0:02 ` Jim C. Brown
2005-02-10 1:28 ` Nathaniel McCallum
2005-02-10 2:34 ` Jim C. Brown
2005-02-10 3:47 ` Nathaniel McCallum
2005-02-10 19:59 ` Fabrice Bellard [this message]
2005-02-10 20:32 ` Nathaniel McCallum
2005-02-10 21:21 ` Fabrice Bellard
2005-02-10 22:16 ` Magnus Damm
2005-02-11 11:07 ` Jan Marten Simons
2005-02-11 12:20 ` Johannes Schindelin
2005-02-11 15:07 ` Jim C. Brown
2005-02-11 15:35 ` Nathaniel McCallum
2005-02-11 16:14 ` [Qemu-devel] " Ronald
2005-02-11 23:02 ` Nathaniel McCallum
2005-02-11 23:39 ` [Qemu-devel] " Ronald
2005-02-11 18:27 ` [Qemu-devel] " Jan Marten Simons
2005-02-11 18:30 ` Paul Brook
2005-02-11 20:03 ` Nathaniel McCallum
2005-02-11 22:55 ` art yerkes
2005-02-11 23:04 ` Nathaniel McCallum
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=420BBD21.2070705@bellard.org \
--to=fabrice@bellard.org \
--cc=qemu-devel@nongnu.org \
/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).