On 05/24/2012 09:01 AM, Andreas Färber wrote:
Am 24.05.2012 15:48, schrieb Igor Mammedov:
On 05/24/2012 03:04 PM, Anthony Liguori wrote:
I'm not sure how I feel about this. I never intended for a user to be
able to create objects that were arbitrary children of other objects.
In some ways, I think this is almost too powerful of an interface to
expose to users. I like things like device_add() better that only
creates objects
of TYPE_DEVICE that are always in /peripherial.
For block, we'd have a similar interface that always created objects
of TYPE_BLOCK_DRIVER and put them in /block.
Will we have a special cases for every incompatible device types that is
going to be hot-plugged via device_add monitor command?
For CPUs my thoughts were moving in opposite direction, like:
- make possible to create and initialize CPU as a regular QOM object
- hack qdev_device_add() to allow not only TYPE_DEVICE to be created there
There are patches out there that make cpu a child of /machine at board
level.
But for hot-added objects parent could be specified as a property
or knowledge about parent hard-coded inside of object itself or
hard-coded in device_add().
Which one of them likely to be adopted?
For system emulation I am working towards making the CPU a device so
that we can reuse common device infrastructure:
Ah, perfect, I guess great minds think alike :-)
Regards,
Anthony Liguori
