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

[Anthony Liguori]

On 09/15/2011 08:43 AM, Jan Kiszka wrote:
> On 2011-09-15 00:11, Anthony Liguori wrote:
> > On 09/14/2011 04:15 PM, Jan Kiszka wrote:
> > > On 2011-09-14 21:42, Anthony Liguori wrote:
> > > > > Such names can get fairly long I'm afraid...
> > > >
> > > > A user should never even see these names.  A user probably will always
> > > > interact with devices via paths.
> > >
> > > Right.
> > > <scratching head>
> > > But will those automatic names be used at all then?
> >
> > Yes, because QEMU is not going to know anything about path names :-)
>
> I bet that's a needless self-restriction. What prevents reusing the
> introspection services that allow path resolutions on the client side
> also QEMU internally? It would enable us to skip any traps and pitfalls
> associated with unique device name construction. From a higher
> perspective, they are completely redundant.

I actually agree :-)

We should probably pick a path format and implement in QMP.  I think that 
discussion is orthogonal though.

> > Path names should be a concept that exists entirely in the client.  That
> > may be HMP or that may be a command line tool (like the proposed qemu
> > script).
> >
> > The only management interface exposed to the client is:
> >
> > create_object(type, name)
> > value = get_object_property(name, property_name)
> > void set_object_property(name, property_name, value)
> > props = list_object_properties(name)
> > names = list_objects()
> >
> > So names are very important from a QMP perspective, but not something
> > users every really see.
>
> I don't get the added value of something that looks almost like a path
> but is still not as readable at it (e.g. when debugging the communication).

It's two separate namespaces.  The name namespace is controlled by the user and 
we have to bend over backwards to avoid clashing with it.

The path namespace is controller by QEMU (more or less).

The name namespace also maps 1-1 to devices which means names can be used to 
represent devices.  They absolutely never change as long as the device never 
changes.

Paths maps N-1 to devices.  Paths may change but names never change.  I don't 
think there can ever be a fixed canonical path.

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.

> >  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.

Regards,

Anthony Liguori

> Jan