> > 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 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. I see no reason to require the driver name, or to include it in the canonical device address. > > An easy way to get that is to reserve part of the name space for bus > > addresses. If the path component starts with a letter, it's an ID or > > driver name. If it starts with say '@', it's a bus address in > > bus-specific syntax. The bus provides a method to look it up. > > I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is > set for buses that implement some to-be-defined device addressing > service, the latter is the default on buses where that service is not > available. If we have bus-address then I see no good reason to also add instance-no. For busses that no natural address, we can define the address to be an instance number. > > 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. 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
