[Top][All Lists]
[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: |
Sun, 01 Jul 2012 14:24:55 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 |
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 ...
Orit
>
> Thanks, Juan.
>