On Wed, Jun 05, 2013 at 07:04:59PM +0200, Andreas Färber wrote: > Am 05.06.2013 16:39, schrieb Igor Mammedov: > > On Wed, 05 Jun 2013 15:29:08 +0200 > > Andreas Färber <afaer...@suse.de> wrote: > > > >> Am 05.06.2013 15:18, schrieb Igor Mammedov: > >>> It's a rebase of v7 on current qom-cpu tree, since then some patches from > >>> it > >>> were applied to master. Convertion of feature bits is left for part 2 > >>> since it's not ready yet. > >>> > >>> v7-v8: > >>> * split out dynamic properties convertion patch into per property patches > >>> to simplify review > >>> * drop feature bits convertion > >> > >> Why is conversion of dynamic properties to static properties still > >> needed after I applied a solution to override values of dynamic > >> properties with -global for 1.5? > > Do you mean qdev_prop_set_globals_for_type() & co? > > Yes. > > > If yes, then I recall it was acceptable hack to permit more clean > > approach for compat props fixes to work. And we promised Anthony to > > get rid of it when possible. > > Indeed, but no one talked about reverting to static properties as the > solution. :) Instead I was talking about solving this very general > problem at DeviceState / QOM level.
We have had this discussion before, and I remember Anthony saying that anything set using global properties _must_ be static properties, period. That was the main motivation we even started doing the static properties work, months ago. > > > Now more to the point, > > > > 1. if CPU are to be created with device_add(wich is still a goal) > > cpu_x86_create() won't be created, so it leaves rules out compat > > properties set by qdev_prop_set_globals_for_type(). > > It does not rule it out, but I think we all agree that we do not want > calls of it cluttered over subclasses. > > Instead we have a very generic problem: instance_init is called > recursively, parents first, so a parent class cannot do any instance > initialization *after* its derived classes initialized the instance. > That's contrary to how realize and other QOM methods work but in > exchange for the flexibility put the burden of saving and calling the > parent's implementation onto subclasses. > > That's what I would like to change in some way, possibly a > instance_post_init hook or the like, similar to how DeviceState got its > own base class initialization hook to handle static props. > That would not only keep the work low in this case but may also solve > the virtio-net initialization problem reported elsewhere. You mean this? https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg00434.html > [...] -- Eduardo