Il 02/05/2014 16:43, Eduardo Habkost ha scritto:
The first thing I considered was making icc-bus user-creatable. Then I
noticed it wouldn't work because object-add always add objects to
/objects, not inside the qdev hierarchy (that's where device_add looks
for the bus).
So, allowing device_add could be possible, but would require changing
more basic infrastructure: either allowing bus-less devices on
device_add, or allowing device_add to add devices outside the qdev
hierarchy, or allowing object-add to create objects outside /objects.
Simply making CPU objects work with object-add was much simpler and less
intrusive. And it had the interesting side-effect of _not_ doing things
that are not required for CPU model probing (like creating an actual
VCPU thread).
I like this series in general. I have only some doubts about making the
code somewhat future-proof, hence the three questions I have are really
variations of this same doubt:
* is it worthwhile to extend this to other devices, for management to
query default values of the properties?
* how does this interact with future QOMification of device hotplug
where devices will be hotplugged with object-add? Should
Device::UserCreatable::complete set realized to true in this case in the
future? How will Device::UserCreatable::complete distinguish the two cases?
* Related to this, if Device::UserCreatable::complete will set realized
to true, how will we handle hotplug of interconnected devices where
device 1 needs a link to device 2 and device 2 needs a link to device 1?
Paolo
