Paul Brook wrote: >>>> 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? > > Autocompletion can report all of them. Autocompletion can only provide what is later on parseable. It doesn't help to see "e1000" and "03.0" as device addresses because you do not know their relation that way. Only combining the information into a single name does. > Errors should report either what the > user specified (if the problem is with the address), or the canonical address > (if the problem is unrelated to the address). > > Remember that we also have global aliases (paths that do not begin with "/"). They only help if the user set them and therefore should know their semantics. > >>>>> 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. > > I don't think either of these are intuitive. There's a good chance that > isa-serial.0 will not correspond to the first serial port in the guest. Only if you start tweaking the base addresses. Then it will still correspond to the addition order AND the user should be aware of this special setup. > Much better would be allowing use of IO port or MMIO addresses to identify ISA > devices. Some modification to the ISABus code may be required to implement > this. Works for serial, but fails for ISA devices not occupying an address. 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
