Alex Williamson wrote: > On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote: >>>>> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci" >> There's a device missing between the main system bus and the pci bus. Should >> be something like: >> >> /main-system-bus/piix4-pcihost/pci.0/_09.0 > > Ok, I can easily come up with: > > /System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virtio-blk First two elements are redundant, '/' already stands for the main system bus. Then I don't get what last element expresses (the target device is virtio-blk-pci). Is this due to some vmstate layout? But that should not be part into qdev paths (maybe I'm missing your use case). And instead of introducing another hierarchy level with the bus address, I would also prefer to add this as prefix or suffix to the device name, e.g. <driver>.<busaddr>. > > to expand the previous output. Code below. > >>>> Could you explain why you add "identified properties of the immediate >>>> parent bus and device"? They make the result ver much *not* a "dev >>>> path" in the qdev sense... >>> In order to try to get a unique string. Without looking into device >>> properties, two e1000s would both be: >>> >>> /main-system-bus/pci.0/e1000 >>> /main-system-bus/pci.0/e1000 >>> >>> Which is no better than simply "e1000" and would require us to fall back >>> to instance ids again. The goal here is that anything that makes use of >>> passing a dev when registering a vmstate gets an instance id of zero. >> You already got the information you need, you just put it in the wrong place. >> The canonical ID for the device could be its bus address. In practice we'd >> probably want to allow the user to specify it by name, provided these are >> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would >> as an aias for [...]:_09.0. > > Sure, if there was a guaranteed unique char* on a DeviceState that was > consistent between guest invocations, we could just use that instead. I > suppose all devices could have a global system id property and if that > was present we'd use that instead of creating the device path. > >> Device names have a restricted namespace, so we >> can use an initial prefix to disambiguate a name/label from a bus address. > > I'm not sure it's necessary. It seems like it would only be necessary > to differentiate the two if we wanted to translate between namespaces. > But I think it's reasonable to require that if a global name is > provided, it must always be provided for the life of the VM. > >> For busses that don't have a consistent addressing scheme then some sort of >> instance ID is unavoidable. I guess it may be possible to invent something >> based on other device properties (e.g. address of the first IO port/memory >> region). > > Instance IDs aren't always bad, we just run into trouble with hotplug > and maybe creating unique ramblock names. But, such busses typically > don't support hotplug and don't have multiple instances of the same > device on the bus, so I don't expect us to hit many issues there as long > as we can get a stable address path. Thanks, > If stable instance numbers are required, we could simply keep them in DeviceState and search for the smallest free one on additions. Actually, I'm more in favor of this direction than including the bus address. That way we could keep a canonical format across all buses and do not have to provide possibly complex ID generation rules for each of them. BTW, the problem isn't truly solved by printing paths. We also need to parse them. It would be counterproductive if such paths ever see the light of day (ie. "leak" outside vmstate) and a user tries to hack it into the monitor or pass it on the command line. With my series, I'm currently able to process paths like this one: /i440FX-pcihost.0/pci.0/PIIX4_PM.0/i2c/smbus-eeprom.6 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
