On Wed, Feb 23, 2011 at 3:31 PM, Avi Kivity <a...@redhat.com> wrote: > On 02/23/2011 04:35 PM, Anthony Liguori wrote: >> >> QEMU uses the state database to store information that is created >> dynamically. For instance, devices added through device_add. A device >> added via -device wouldn't necessary get added to the state database. >> >> Practically speaking, it let's you invoke QEMU with a fixed command line, >> while still using the monitor to make changes that would otherwise require >> the command line being updated. > > Then the invoker quickly loses track of what the actual state is. It can't > just remember which commands it issued (presumably in response to the user > updating user visible state). It has to parse the stateful config file qemu > outputs. But at which points should it parse it? > > I don't think it's reasonable to have three different ways to interact with > qemu, all needed: the command line, reading and writing the stateful config > file, and the monitor. I'd rather push for starting qemu with a blank guest > and assembling (cold-plugging) all the hardware via the monitor before > starting the guest.
This is why I asked about unifying the stateful config with qdev or QemuOpts in the machine init mailing list thread. If we have n different ways of toggling things inside QEMU including command-line, HMP, QMP, and stateful config, then a large chunk of QEMU is just going to be parsing and formatting these external interfaces. Stefan
