On 02/07/2012 03:56 PM, Anthony Liguori wrote:
Another related question is, should the 4th QOM series present a full
composition tree based on the legacy qdev bus concept?
Composition, no. The legacy qbus concept doesn't model composition
because it puts children created by composition (like the Cirrus VGA
adapter) in the same context as a device created by a user (like an
e1000 network card).
Currently it doesn't, but
if not, why not? That would help _a lot_ with removing PROP_PTR.
One thing that we could do, is modify qdev_create() like:
DeviceState *qdev_create_with_name(BusState *bus, const char *typename,
const char *name)
{
// ...
object_property_add_child(legacy_machine_root(), name, OBJECT(dev), &err);
// assert if err due to conflicting property names
}
DeviceState *qdev_create(BusState *bus, const char *typename)
{
return qdev_create_with_name(bus, typename, typename);
}
Most devices only have a single instance. In the cases where there are
multiple instances, we'll have to fix it up manually but that really
shouldn't be all that hard.
I'm wary of all plans that require to go through all the code once.
What about simply /devices/default/child[...] or something like that?
BTW, I would like to change /i440fx to /devices/i440fx, so that we will
have clean namespaces:
/block
...
/chardev
...
/clocks
...
/devices
/peripheral
... # named devices created with -device
/peripheral-anon
/child[...] # unnamed devices created with -device
/default
/child[...] # created with qdev_create
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
