Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Markus Armbruster wrote:
>>>>> That way, we gain a useful feature, and avoid having an savevm-specific
>>>>> "device path" that isn't recognized anywhere else.
>>>> Agreed, we should find one solution for all use cases.
>>> I wasn't aware that there was any suggestion of a separate savevm-specific 
>>> path.  The whole point of a device path is to uniquely identify a device 
>>> within a machine. There may be many different paths that identify the same 
>>> device.  When given a device and asked to generate  path, the result should be 
>>> the canonical address.  IMO this should be the least volatile, and avoid 
>>> redundant information.
>> Given that it is also user-visible, it should also have an intuitive and
>> informative format to avoid confusions. That may imply slightly more
>> information than strictly required for machine-based processing.
> 
> I'm with Paul here.

Well, what I'm proposing is derived from my experiences collected while
playing with device_show and device_add/del over the past weeks. For
these monitor scenarios, it was very handy to have expressive path
elements which avoid having to issue 'info qtree' all the time (which is
annoying if you are in the middle of a command input).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux