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

[Kevin Wolf]

Am 15.09.2011 16:11, schrieb 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.

Maybe then the device name shouldn't default to something that looks
like a path but rather something like "#foo-1" where "foo" is a device
name and "1" a counter for devices of the same type (I'm reusing Jan's #
notation in order to avoid clashes with user specified names, but that's
a detail). I guess a name like that would actually be relatively
convenient to use from a user interface like HMP.

Kevin