Re: [Qemu-devel] [RFC] Plan for moving forward with QOM

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-09-15 16:11, Anthony Liguori wrote:
> An example is a NIC with nvram that stores a mac address.  In QOM, the guest 
> could change the mac address, then a user could hot unplug the device, and then 
> hot plug the device into a different PCI slot.  The path is now different but 
> the device name has not change.

One of the many paths is still "<unique-nic-name>/nvram", so nothing
changed.

Auto-generated names are not needed, just use paths. In the end a device
name is a path as well, one with only a single element.

>>>  From a client perspective, yes.  The scripts I showed at KVM Forum had
>>> '/' return the list of all user-created devices as the contents.  It's a
>>> nice feature but I think it's something that lives in a client, not in
>>> the object model.
>>
>> This is part of the object model as it defines the tree construction and
>> if the root can only be a single target-specific device or a generic,
>> invariant container. This '/' exception as defined so far looks odd to me.
> 
> I don't think I understand you're suggestion of having a special '/' device 
> name.  I think we may be talking past each other.
> 
> In QOM, whenever a device is created, it's created with a name.  This basically is:
> 
> void type_init(void *memory, const char *name)
> {
>     global_object_hash_table[name] = memory;
> }
> 
> Looking up a device by name is just a hash table lookup.  In the case of 
> composition, you have:
> 
> struct MyDevice {
>    struct MyComposedDevice foo;
>    MyDevice *sibling;
> };
> 
> void my_device_init(MyDevice *obj, const char *name)
> {
>      type_init(obj, name);
>      type_init(&obj->foo, name + "::foo");
> }
> 
> Which gives you two devices in the global hash table.  Links are created by 
> basically having:
> 
> void my_device_set_sibling(MyDevice *obj, MyDevice *sibling)
> {
>     obj->sibling = sibling;
> }
> 
> void my_device_init(MyDevice *obj, const char *name)
> {
>      ...
>      type_add_property(&obj, "sibling", my_device_set_sibling, "link<MyDevice>");
> }
> 
> type_add_property() has special sauce that lets you write the "sibling" property 
> as a string, does the lookup and error checking, and ultimately calls 
> my_device_set_sibling() with a Device * pointer.
> 
> There is no root.  You can create many completely separate graphs.

You need a "default" root to make the graphs reasonably discoverable. If
I ask QEMU "How does my system look like?" I don't want to get a flat
list of all devices in it. Roots are where creation started, the
chipsets, the SOCs etc. It's an organizational matter at least, but
that's one thing what paths are about...

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux