> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote: > > > > Alex proposed to disambiguate by adding "identified properties of the > > > > immediate parent bus and device" to the path component. For PCI, > > > > these are dev.fn. Likewise for any other bus where devices have > > > > unambigous bus address. The driver name carries no information! > > > > > > From user POV, driver names are very handly to address a device > > > intuitively - except for the case you have tones of devices on the same > > > bus that are handled by the same driver. For that case we need to > > > augment the device name with a useful per-bus ID, derived from the bus > > > address where available, otherwise based on instance numbers. > > > > This is where I think you're missing a trick. We don't need to augment > > the name, we just need to allow the bus id to be used instead. > > For the case of a hot remove, I agree. If the user specifies "pci_del > pci.0/03.0", that's completely sufficient because we don't care what's > in that slot, just remove it. However, I still see some use cases for > device names in the path. Take for example: > > (A): /i440FX-pcihost/pci.0/e1000.05.0 > > vs > > (B): /pci.0/05.0 > (removing both the root bridge driver name and the device driver name) This is wrong. You still need an entry for the host pci bridge. > If we attach a pci option rom to the device, create some ram to store > the option rom and name the ram block $(PATH)/rom, with (A) we know more > about the hierarchy to get to the actual devfn device, and we know the > type of device that's in the slot. With (B), there's no robustness. If > we migrated using (B), we could be stuffing a pc e1000 option rom into a > ppc lsi895, just because it happened to live that the same place and > have a ram block named rom. Including driver names increases the > uniqueness of the path. No it doesn't. It adds redundant information and a false sense of security. Driver name is not sufficient to determine whether you've actually got a compatible device. The type of the device doesn't reliably tell you anything about how many ram blocks that device has, or how big they are. > > > > For other buses, we need to make something up. > > > > > > > > Note that addressing by bus address rather than name is generally > > > > useful, not just in the context of savevm. For instance, I'd > > > > appreciate being able to say something like "device_del pci.0/04.0". > > > > > > And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump > > > the bus first before you can identify which device you want to remove. > > > > We can allow both. > > A bus address is sufficient to uniquely identify a device. > > A bus address (assuming it exists) is sufficient to uniquely identify a > device, on a given VM. A bus address only identifies a location when > comparing two separate VMs. I can't make any sense of this statement. > > I see no reason to > > require the driver name, or to include it in the canonical device > > address. > > Migration. Including the driver name extends our ability to uniquely > identify a device across separate VMs. It's then up to the vmstate code > to figure out whether the device are compatible for migrate state. I find this argument contradictory. The migration code already needs to check whether a device is compatible before it allows migration. The driver name is not sufficient to ensure compatibility, so I see no benefit in including it in the device address. If we include the device name, why aren't we also including all other properties that would make the devices incompatible? 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
