Anthony Liguori <anth...@codemonkey.ws> writes: > On 02/23/2011 11:26 AM, Markus Armbruster wrote: >>> 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. >>> >> Exactly. And qdev has brought his within our reach. >> > > Actually, QMP is the star of the show here, not qdev. > > The way we get here is by incrementally converting the option handling > to be qmp calls. For instance, instead of: > > case QEMU_OPTION_name: > qemu_name = optarg; > break; > > We do: > > case QEMU_OPTION_name: > qmp_set_name(optarg, NULL); > break; > > When we can compile vl.c with nothing more than QMP dependencies, > we've achieved the goals here. This will mean adding a lot of new QMP > commands. > > There are some command line options that must be handled before the > machine is initialized and QMP is normally run. For 0.16, we can > introduce a new QMP mode whereas the event loop gets to run before > doing machine init and explicit create_machine() command is needed. > This is the final bit that will be needed to realize this goal. > > A lot of good things come out of this. Quite a lot of these new > commands don't strictly need to run before machine init (like -name) > which means we'll get the ability to change a lot of parameters > without rebooting the guest which couldn't be changed before. > > And this is all incremental stuff that can be done in parallel of the > QAPI work. We just need to do the work of adding the function calls > (or function call wrappers where appropriate).
Well, I wouldn't put "let's create a sane separation between option parsing and machine configuration" under the "QEMU *Monitor* Protocol" flag, but I certainly don't mind you hoisting whatever flag pleases you.
