Re: [Qemu-devel] Just a thought (high level API)

From: "Jim C. Brown" <jma5@umd.edu>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Just a thought (high level API)
Date: Wed, 9 Feb 2005 19:02:29 -0500	[thread overview]
Message-ID: <20050210000229.GA14208@jbrown.mylinuxbox.org> (raw)
In-Reply-To: <1107961744.8824.7.camel@localhost.localdomain>

On Wed, Feb 09, 2005 at 10:09:04AM -0500, 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.

A file that allowed one to use Xliib instead of SDL was release a while back
(you just replaced the real sdl.c with this file and recompiled) but it was
never added to qemu directly.

One reason is because there was no clean way to add it, but it also seems that
Fabrice seems unwilling to add X support directly into qemu. (He has never
explained this, he simply said that he'd accept code for Win32, GTK, and MacOS
graphics support).

The first part can be dealt with by creating a "GUI" api for qemu, with SDL
as the default driver. That would make it easy to stick in other front ends.

>  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!)

There already exists a libqemu.a file that seems to support this. That may
be qemu-user specific however.

>   2. Allow for multiple rendering options (SDL, GTK, QT, win32, etc)

The above idea (creating a GUI api) would be enough for this, unless you want
to add extra (such as QeWS does). We would probably want more than one API
for qemu overall, it already has one for sound support.

Sidenote: it is possible to use only the GUI api for frontends such as QeWS,
they would just need a custom driver that talks to the frontend (and thus the
frontend can directly handle all the graphics itself).

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

I don't understand what you mean by "virtual machine profile".

> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.