qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 02/12] savevm: Live migration handlers register


From: Orit Wasserman
Subject: Re: [Qemu-devel] [PATCH 02/12] savevm: Live migration handlers register the struct directly
Date: Wed, 11 Jul 2012 20:28:21 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

On 07/11/2012 08:01 PM, Juan Quintela wrote:
> Orit Wasserman <address@hidden> wrote:
>> On 07/01/2012 01:20 PM, Juan Quintela wrote:
>>> Orit Wasserman <address@hidden> wrote:
>>>> On 06/28/2012 10:22 PM, Juan Quintela wrote:
>>>>> Notice that the live migration users never unregister, so no problem
>>>>> about freeing the ops structure.
>>>>>  void unregister_savevm(DeviceState *dev, const char *idstr, void *opaque)
>>>>> diff --git a/vl.c b/vl.c
>>>>> index 1329c30..b1f31e8 100644
>>>>> --- a/vl.c
>>>>> +++ b/vl.c
>>>>> @@ -3438,8 +3438,7 @@ int main(int argc, char **argv, char **envp)
>>>>>      default_drive(default_sdcard, snapshot, machine->use_scsi,
>>>>>                    IF_SD, 0, SD_OPTS);
>>>>>
>>>>> -    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
>>>>> -                         ram_load, NULL);
>>>>> +    register_savevm_live(NULL, "ram", 0, 4, &savevm_ram_handlers, NULL);
>>>>>
>>>>
>>>> Juan,
>>>> Can't we move it migration.c (migrate_init and qemu_start_incoming 
>>>> migration)?
>>>> this will remove to use an extern for savevm_ram_handlers.
>>>
>>> savevm_ram_handlers are exported from arch_init.c, what do we win if we
>>> move it?  Furthermore, I add more functions to this extructure later in
>>> the series, so not exporting the structure and having to export more
>>> functions what bring to us?
>> well it shouldn't be in vl.c , there is no reason (correct me if I'm wrong) 
>> to 
>> register "ram" handlers if there is no migration ...
> 
> We always register migration handlers :-(
> 
> The other problem is that there is no other function that we ex
port for
> arch_init.c where we can piggy_back() that registration :-(
> 
Well I guess it can stay as it is for a bit longer ...

Orit
> Later, Juan.
> 





reply via email to

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