From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cz5tc-00062f-6t for qemu-devel@nongnu.org; Wed, 09 Feb 2005 23:25:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cz5tY-0005yv-2r for qemu-devel@nongnu.org; Wed, 09 Feb 2005 23:25:38 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cz5tW-0005t5-DU for qemu-devel@nongnu.org; Wed, 09 Feb 2005 23:25:34 -0500 Received: from [63.240.76.165] (helo=sccimhc91.asp.att.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cz5IJ-0006Ga-Qx for qemu-devel@nongnu.org; Wed, 09 Feb 2005 22:47:08 -0500 Subject: Re: [Qemu-devel] Just a thought (high level API) From: Nathaniel McCallum In-Reply-To: <20050210023426.GA15123@jbrown.mylinuxbox.org> References: <1107961744.8824.7.camel@localhost.localdomain> <20050210000229.GA14208@jbrown.mylinuxbox.org> <1107998888.15048.29.camel@localhost.localdomain> <20050210023426.GA15123@jbrown.mylinuxbox.org> Content-Type: text/plain Date: Wed, 09 Feb 2005 22:47:05 -0500 Message-Id: <1108007226.8060.28.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 Wed, 2005-02-09 at 21:34 -0500, Jim C. Brown wrote: > After thinking about it for a while, your approach is better. I then thought > about taking it a step farther, and we could use multiple processes. The qemu > exectuable would hold the main emulator engine, but it would send graphical > output via a well documented protocol to a front-end process, and console > output to a process (probably the same one but concievably a different one) > via another protocol. Interesting... though this would introduce a level of latency, particularly troublesome when we are using 100% CPU for emulation. We then also have to deal with the IPC issue: UNIX/Linux/Mac can use dbus or a unix socket, Windows can't use either of these. While multiple processes would certainly be more stable, is it worth the complexity it introduces? A well planned out API might give us just as much flexibility with higher performance and portability. One advantage of the protocol/ipc method would be that you get free bindings to any language (ie. any language can use the protocol). However, the main languages that would use the API would be C (console and gtk/gnome), C++ (w32 and qt/kde) and Obj-C (Mac) which can all use the C API without any bindings, so its not a huge advantage unless someone wants to embed qemu into something done in another language. The API wouldn't be that big though, so bindings wouldn't be all that problematic. I'm open to the protcol/multiple processes approach if we can do it with: 1. low latency 2. portability 3. simplicity > In other words, a config file? > > This has already been discussed, and Fabrice mentioned support for .qmu files > a while ago. To my knowledge, these have never been used and I don't know if > they are still supported. > > This approach would only work if all front-ends standardized to the same config > file format, or if this parsing was done directly by the qemu engine ... or if > all front ends invoked a standard parser to handle this. This would go along > with the multiple process idea for the UI. If we put this in the libqemu library from the get go, GUIs will use it. If you notice how I modeled this in the header in my first email: You generate a QEMUVirtualMachine from a QEMUVirtualMachineProfile which you can load from a file or serialize to a file. This standard struct would be the standard place to define virtual machine parameters. > I already have this, but it is done via a shell script that converts the > parameters into command line options. It shouldn't be difficult to convert > it into Python or Perl. (Writing a C program that does the same is also possible, > and should be no more difficult than writing any other C program. ;) It has to be C (portability without massive dependencies), though we may want to use glib. It has great functions for reading and writing config files (in addition to a million other things). glib is getting pretty standard these days and has great Window support. In fact, from what I can see, glib would in some places reduce the code quite a bit in qemu. Nathaniel