Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail()

[Paolo Bonzini]

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