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

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

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.

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

> 
>>
>>>
>>> We can also look at doing things like user-defined aliases or something
>>> like that.
>>
>> ...or a way to set the name of an auto-generated device via its pathname.
> 
> The auto-generated name is already basically generated from a pathname. 
> But that path isn't necessarily the obvious one from a user's point of
> view.
> 
>>>>> Since a bus is-a device in QOM, there is no notion of having multiple
>>>>> busses
>>>>> under the same device.  A device can implement multiple bus
>>>>> interfaces,
>>>>> but can
>>>>> only be a single bus of any given bus interface.
>>>>>
>>>>> Device names are completely independent of pathnames.  For devices
>>>>> that
>>>>> are no
>>>>> user created, device names should be treated as opaque blobs with
>>>>> absolutely no
>>>>> semantic meaning.
>>>>>
>>>>> All device relationships are identified as named properties.  A QOM
>>>>> path
>>>>> name
>>>>> consists of a named device,
>>>>
>>>> With a system root device called '/'. So '/' is another
>>>> character(-sequence) that is forbidden in device names.
>>>
>>> Yes, but there is no system root device.
>>
>> There is always a generic link to some root device. I think it would be
>> more regular to make that link an abstract device called '/' - maybe
>> even one that can hold a larger number of children. Keeps the door open
>> for crazy multi-root systems models.
> 
> 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.

Jan

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