Jan Kiszka <jan.kiszka@xxxxxxxxxxx> writes: > 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. > > I prefer having one name per device, both unique AND human-friendly. > Adding yet another alias will solve only the first requirement. E.g., > which one should I present to the monitor user when listing a bus for > auto-completion or path error reporting? > >> >>>> 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. > > Readability and simplicity (less aliases - for the same reason, I'm > removing ID-based addresses from qtree paths, restricting them to the > global, flat namespace). > >> >>>> 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. > > Again readability: isa-serial.0 & isa-serial.1 is more intuitive than > isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA > devices registered before them. Readability is in the eye of the beholder. If the beholder wants to number his serial devices a certain way, he better makes his wishes known with id=, because the system has a hard time guessing them. >>>> 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. -- 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
