From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cz29a-0006gO-4j for qemu-devel@nongnu.org; Wed, 09 Feb 2005 19:25:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cz29W-0006di-Cx for qemu-devel@nongnu.org; Wed, 09 Feb 2005 19:25:51 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cz29W-0006Yh-1N for qemu-devel@nongnu.org; Wed, 09 Feb 2005 19:25:50 -0500 Received: from [128.8.10.164] (helo=po2.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cz1mx-0002mZ-0r for qemu-devel@nongnu.org; Wed, 09 Feb 2005 19:02:31 -0500 Received: from jbrown.mylinuxbox.org (jma-box.student.umd.edu [129.2.237.180]) by po2.wam.umd.edu (8.12.10/8.12.10) with ESMTP id j1A02TZl000607 for ; Wed, 9 Feb 2005 19:02:29 -0500 (EST) Date: Wed, 9 Feb 2005 19:02:29 -0500 From: "Jim C. Brown" Subject: Re: [Qemu-devel] Just a thought (high level API) Message-ID: <20050210000229.GA14208@jbrown.mylinuxbox.org> References: <1107961744.8824.7.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107961744.8824.7.camel@localhost.localdomain> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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.