Il 12/04/2012 15:58, Andreas Färber ha scritto: > The big clash that Paolo and I had turned out to stem from tackling two > virtually inconsolable goals, both under the banner of "realize":
I think the code was similar enough that the goals are not unreconcilable (though QOM goals can certainly become sad if they aren't achieved in a few years :). > 1) Me and Peter need a way to do two-stage construction of non-qdev > objects. Inlining the below code into lots of machine init functions is > a really bad suggestion IMO. FWIW, I agree. > I don't see 2) working at this stage due to the very simple fact that we > create objects in the second stage depending on properties. Do you have examples? As long as the objects are created in the realize method itself you can do that. > The one-realize model is also incompatible with the static properties > concept that Paolo is moving into object in this series - we'd need to > make them dynamic properties that actually do something when set (e.g., > modify the offset of a particular child MemoryRegion). The child MemoryRegion could be created at realize time as long as the composition tree hierarchy is correct. A child's MR can use a MR property that the parent creates at realize time, because the parent is always realized first and unrealized last. Some properties however might need to become dynamic, for example a SOC's number_of_uarts property would create children before realization. > i) Moving vcpu_init() from cpu_*_init() into a realizefn. This is compatible with realize-once-at-machine-creation. > ii) Instantiating an SoC container object with varying CPU. This seems similar to the MemoryRegion case. > iii) Moving ARM feature inference into a realizefn. I don't know anything at all about this. :) If you need it as a stopgap measure, you could have cpu_realize_nofail in qom/cpu.h. I wouldn't at all oppose to that. But it shouldn't be encouraged, IMO. Paolo
