On Tue, 13 Jun 2017 11:12:17 +0100 "Dr. David Alan Gilbert" <dgilb...@redhat.com> wrote: [...] > > > > > > > > > > So what's the problem with a (void *)i ? > > > > > > > > https://stackoverflow.com/questions/8618637/what-does-it-mean-to-convert-int-to-void-or-vice-versa > > > > > > > > > It's simple, as long as you're > > > > > not actually using the opaque anywhere it's easy. > > > > > > > > > > > > > but as you say, since the opaque isn't used anywhere, it is probably > > > > okay to pass (void *) i. > > > > > > Yes, I don't think we're ever casting back from the (void *) to an int > > > so it feels pretty safe to me. > > > > > > > Just one nit, gcc doesn't like it on 64-bit hosts: > > > > hw/ppc/spapr.c: In function ‘pre_2_10_vmstate_register_dummy_icp’: > > hw/ppc/spapr.c:148:60: error: cast to pointer from integer of different > > size [-Werror=int-to-pointer-cast] > > vmstate_register(NULL, i, &pre_2_10_vmstate_dummy_icp, (void *) i); > > > > I need to cast to (long) first. > > Try casting to a uintptr_t first. >
Yeah, you're right. The standard doesn't guarantees whether pointers have the size of int or long. I'll use intptr_t. Thanks for the suggestion. > Dave > > > > > > > > > > Note from a quick glance at your patch; will this work migrating > > > > > from this 2.10 -> 2.9 ? Are your dummy vmstate's really good enough > > > > > for > > > > > the 2.9 ? > > > > > > > > > > > > > Yeah but I need to add some comments as David suggested. > > > > > > > > The idea is that 2.9 used to create a bunch of objects at machine init, > > > > that only get used when CPUs are plugged. With 2.10, these objects are > > > > now created under the CPUs. When migrating from 2.10 to 2.9, we only > > > > need > > > > to send the real objects. The dummy vmstate entries don't send anything > > > > (.needed always returns false) since the corresponding objects in 2.9 > > > > aren't > > > > being used and still have their default state. > > > > > > > > > > OK, that'll probably work. > > > > > > > Thanks for this confirmation. > > > > > Dave > > > > > > > > Dave > > > > > > > > > > > > > > > > -- > > > > > > Greg > > > > > > > > > > > > > > > -- > > > > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > > > > > > > > > > > > -- > > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > > > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
pgpfcXOYBbubk.pgp
Description: OpenPGP digital signature
