> 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/virti > o-blk No. Now you've got way to many elements in the path. My point is that you replace the name of the device with the bus address of the device. However you determine the element names the path should be /busname/devicename pairs. I'm undecided whether the root element should be the main system bus, or a system device node that contains the main system bus. > > 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. All we require is some way of uniquely addressing each device on the bus. For PCI that's trivial (devfn). For other busses we get to pick something appropriate. > > 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. I don't think requiring that all devices are given a globally unique name is going to fly. locally (per-bus) unique user-specified are still a PITA, but may be acceptable. Having a canonical addressing system that's independent of user assigned IDs seems like a good thing. > > 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, Simple consecutive instance IDs are inherently unstable. They depend on teh order of device creation. The ID really wants to be something that can be reliably determined from the device bus itself (and/or its interaction with its parent bus). Paul -- 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
