qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH] Split machine creation from the main loop


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Re: [PATCH] Split machine creation from the main loop
Date: Thu, 24 Feb 2011 10:19:47 +0000

On Thu, Feb 24, 2011 at 12:36 AM, Anthony Liguori <address@hidden> wrote:
> On 02/23/2011 05:38 PM, Juan Quintela wrote:
>>
>> Anthony Liguori<address@hidden>  wrote:
>>
>>>
>>> On 02/23/2011 05:00 PM, Juan Quintela wrote:
>>>
>>>>
>>>> Anthony Liguori<address@hidden>   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<address@hidden>
>>>>>
>>>>>
>>>>
>>>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]