On Thu, Feb 24, 2011 at 12:36 AM, Anthony Liguori <anth...@codemonkey.ws> wrote: > On 02/23/2011 05:38 PM, Juan Quintela wrote: >> >> Anthony Liguori<anth...@codemonkey.ws> wrote: >> >>> >>> On 02/23/2011 05:00 PM, Juan Quintela wrote: >>> >>>> >>>> Anthony Liguori<aligu...@us.ibm.com> wrote: >>>> >>>> >>>>> >>>>> The goal is to enable the monitor to run independently of whether the >>>>> machine >>>>> has been created such that the monitor can be used to specify all of >>>>> the >>>>> parameters for machine initialization. >>>>> >>>>> Signed-off-by: Anthony Liguori<aligu...@us.ibm.com> >>>>> >>>>> >>>> >>>> I agree that it is one step in the right direction, but we are still >>>> calling qemu_machine_init() before calling the main_loop(). >>>> >>>> What is the plan from here? >>>> >>>> >>> >>> 1) Decouple QMP from qemu_machine_init(). This really requires the >>> introduction of the new QAPI server that exists outside of the chardev >>> infrastructure since chardevs are currently initialized in >>> qemu_machine_init(). >>> >>> 2) Make qemu_machine_init() take no parameters and just reference >>> global state. >>> >> >> Any good idea how that global state is going to be stored? >> >> I just want to be able to launch a qemu on a different machine and >> migrate the "configuration" to it, for doing that, I really need what >> values are different from default or anything like that. So as you can >> see, I am very interested on that work. >> > > First step is to have everything go through QMP. If everything flows > through QMP, we have a gateway that we can focus on. > > What I'd like to do next is introduce the notion of a stateful config file.
Any chance of reusing info qtree, QemuOpts, or other existing infrastructure for the config file? Config file set/get/format code tends to be just toggling variables and manipulating strings. There is similarity here with the option parsing and qdev properties. Stefan
