From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C334Q-0002V2-9u for qemu-devel@nongnu.org; Thu, 02 Sep 2004 21:40:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C334P-0002Up-Ll for qemu-devel@nongnu.org; Thu, 02 Sep 2004 21:40:54 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C334P-0002Uk-Gd for qemu-devel@nongnu.org; Thu, 02 Sep 2004 21:40:53 -0400 Received: from [216.254.0.204] (helo=mail4.speakeasy.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1C32yy-000190-3g for qemu-devel@nongnu.org; Thu, 02 Sep 2004 21:35:16 -0400 Received: from dsl081-088-222.lax1.dsl.speakeasy.net (HELO [192.168.111.2]) ([64.81.88.222]) (envelope-sender ) by mail4.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 3 Sep 2004 01:35:14 -0000 Subject: Re: [Qemu-devel] Qemu development schedule? From: "John R. Hogerhuis" In-Reply-To: <20040903001317.GB22689@jbrown.mylinuxbox.org> References: <200408310107.07350.hetz@witch.dyndns.org> <002101c48ee5$46b2e280$20389c3f@computername> <1093908872.26682.76.camel@aragorn> <1C8FBBB0-FB2F-11D8-8B6F-000A95D874F4@mac.com> <1093973009.29476.16.camel@sherbert> <4134DF1A.4010407@bellard.org> <20040901215857.GA21314@jbrown.mylinuxbox.org> <20040902092645.A15294@bbland> <20040902205633.GB21292@jbrown.mylinuxbox.org> <20040902235357.GA1789@aplik.cl> <20040903001317.GB22689@jbrown.mylinuxbox.org> Content-Type: text/plain Message-Id: <1094175358.16486.227.camel@aragorn> Mime-Version: 1.0 Date: Thu, 02 Sep 2004 18:35:58 -0700 Content-Transfer-Encoding: 7bit Reply-To: jhoger@pobox.com, 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 With a control API the console stuff would be rewritten to access the core via control API. FWIW I think a control API makes a lot of sense. Then GUIs can be added at will. It also opens the door to making QEMU fully scriptable which sounds very powerful to me. Imagine being able to start the emulation, monitor the processor, and pull an image of some portion of RAM or the display when some condition occurs. Talk about making VmWare play catch-up! Here's a rough sketch of the work, Features: For now I would take anything that is currently available via the monitor and divide it into properties and actions. We'd have a couple of functions and table driven implementation for the property handling. Very little code. For the actions we just pass through to the core of QEMU as presently do Roadbump: We need to add lifecycle Some properties can only be modified before the emulation is activated. So there may be a simple active/inactive state machine, or something more complex which guards the properties from being diddled at inappropriate times. Most of the API is going to be properties which one can get/set. But given the nature of this being running virtual machines, a lot of those properties only make sense in certain states. For example, you can't change the amount of RAM available to a guest after it is launched, but you can change it any other time. You can get the amount of RAM in use or associated with a guest any time. So basically there is at least a simple active/inactive lifecycle, but there may be a more complex lifecycle state machine. There may be other properties that can be changed at runtime. Basically anything you can currently manipulate from the monitor that is not a function call, but just a change of property. Haven't taken a hard look, most of this probably there in some form, but may want to give QEMU core would get the following generic interface init - init qemu cleanup - cleanup qemu create - create a vm destroy - destroy a vm activate - activate a vm deactivate - deactivate a vm prop_get prop_set + you need to add functions for each action which QEMU exposes on the virtual machine (like power on/off, reset, save state, etc.) init allows qemu to set up any globals. activate is what happens after you're done with parameterization (properties that must be set before the machine is in steady state). Other related design issues? -- John.