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
