[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/3] Add new utility function memory_region_allo
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 0/3] Add new utility function memory_region_allocate_aux_memory() |
Date: |
Fri, 7 Jul 2017 14:03:37 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 |
On 07/07/2017 13:58, Peter Maydell wrote:
>>>
>>> memory_region_init_ram(mr, owner, name, ram_size, &err);
>>> if (err) {
>>> error_propagate(errp, err);
>>> return;
>>> }
>>> /* Note that owner_dev may be NULL if owner is not a DeviceState;
>>> * in that case this is equivalent to calling
>>> vmstate_register_ram_global().
>>> */
>>> owner_dev = object_dynamic_cast(owner, TYPE_DEVICE);
>>> vmstate_register_ram(mr, owner_dev);
>> Maybe, for memory_region_init_ram only, the owner argument can be made a
>> DeviceState (or NULL)?
> Hmm. I don't much like the way that breaks the symmetry of the
> API with the other memory region init functions, and it makes
> it harder to script the conversion. I'd rather keep it as an
> Object*, especially since the only purpose of the pointer is to
> make the RAM name unique for migration purposes.
In that case, I would assert the object is a device and add a TODO to
support non-device objects.
Paolo
> (Better still would be if we had a uniquification mechanism
> for Objects...)
- Re: [Qemu-devel] [PATCH 0/3] Add new utility function memory_region_allocate_aux_memory(), (continued)
Re: [Qemu-devel] [PATCH 0/3] Add new utility function memory_region_allocate_aux_memory(), Peter Maydell, 2017/07/06
Re: [Qemu-devel] [PATCH 0/3] Add new utility function memory_region_allocate_aux_memory(), Peter Maydell, 2017/07/07
Re: [Qemu-devel] [PATCH 0/3] Add new utility function memory_region_allocate_aux_memory(),
Paolo Bonzini <=