Re: [Qemu-devel] Qemu development schedule?

[John R. Hogerhuis]

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.