From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CzLM9-0005tu-RC for qemu-devel@nongnu.org; Thu, 10 Feb 2005 15:56:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CzLM7-0005sc-K9 for qemu-devel@nongnu.org; Thu, 10 Feb 2005 15:56:08 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CzLM7-0005sZ-Gn for qemu-devel@nongnu.org; Thu, 10 Feb 2005 15:56:07 -0500 Received: from [209.94.102.73] (helo=carmine.bestweb.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CzL7W-0006u1-L4 for qemu-devel@nongnu.org; Thu, 10 Feb 2005 15:41:02 -0500 Received: from [192.168.2.46] (moses.asburyseminary.edu [198.160.139.7]) by carmine.bestweb.net (Postfix) with ESMTP id 4F72B232AE for ; Thu, 10 Feb 2005 15:41:02 -0500 (EST) Subject: Re: [Qemu-devel] Just a thought (high level API) From: Nathaniel McCallum In-Reply-To: <420BBD21.2070705@bellard.org> References: <1107961744.8824.7.camel@localhost.localdomain> <420BBD21.2070705@bellard.org> Content-Type: text/plain Date: Thu, 10 Feb 2005 15:32:44 -0500 Message-Id: <1108067564.8083.7.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Thu, 2005-02-10 at 20:59 +0100, Fabrice Bellard wrote: > 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. Thanks for your input! I was hoping you'd come out and play ;). I'll gladly do a gtk frontend (I was planning on it). However, one of the first things I would need to do would be to create some kind of config file to store the settings in. I'd rather do this upstream and let other front ends benefit from this as well. I'm also curious as to your opinion on glib. I've noticed several places in the code where qemu has reimplimented several things that would be much simpler to just use glib for (with its wide os-independant support). Particularly: string functions, error reporting, main loops, memory allocation, etc. As a test, I've been going through qemu-img.c converting it to glib. So far I've got about 100 lines less code and I'm only a quarter of the way through the file. Do you have any objections to a glib dependency? Nathaniel