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
