On 07/07/2017 12:43, Peter Maydell wrote: > On 6 July 2017 at 18:47, Peter Maydell <peter.mayd...@linaro.org> wrote: >> On 6 July 2017 at 18:26, Paolo Bonzini <pbonz...@redhat.com> wrote: >>> Maybe, for memory_region_init_ram only, the owner argument can be made a >>> DeviceState (or NULL)? >> >> Something that might influence things here -- of the twelve >> callers of vmstate_register_ram(), only 6 use an 'owner' >> pointer that's the same as the one they use for initializing >> the memory region (and 3 of those are using _init_rom or >> _init_rom_device rather than init_ram directly). > > Conversely there are 14 or so places that init a RAM MR > with a non-NULL owner but then use vmstate_register_ram_global > rather than vmstate_register_ram, and so which would be > stuck using the old _nomigrate() function if we make it > use the owner pointer.
I think whenever feasible we should pay the price of breaking migration. I found these: - aspeed_soc_realize - integratorcm_init - onenand_initfn (nseries) - cg3_initfn (one init_ram in there is not using owner, might be changed as well) - sm501_init - tcx_initfn - milkymist_softusb_init - milkymist_minimac2_init - raven_realize - idreg_init1 - afx_init1 - prom_init1 (two functions with the same name in two files) - ram_realize - lx60_net_init The only problematic one for backwards compatibility is rom_set_mr. > I guess we should think about the long term and design > the API to encourage the behaviour we want for new code, > rather than to catch as much of possible of existing > usage, though? Yes, though that leaves the possibility of people copying from the wrong code, so if we can break migration compatibility that would be better in the long term. Paolo