Paul Brook wrote: >> 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. > > Of course. > >> 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. > > I don't get your argument here. Why shouldn't e1000 and @03.0 refer to the > same device? Querying the device itself will tell you both, so it's not hard > to figure out that they refer to the same thing. Either piece of information > is sufficient, so why do we require both? To avoid having to issue an "info qtree" in the middle of an auto-completion for some other command. > > Note that autocompletion and enumeration for mechanical traversal are > different problems. The former should include useful aliases for humans (i.e. > both e1000 and @03.0). The latter should be limited to the unique values > corresponding to canonical addresses (i.e. @03.0). > >>>> 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. > > I'm pretty sure there are some machines that have both internal UARTs > (considered to be the primary ports), and secondary ports on an ISA bus. > > If you really want instance numbers, then they may make most sense appended to > the driver name. However I think this should be independent of bus addressing, > and bus addresses make most sense as the canonical address. That's how my current implementation looks like. > >>> 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. > > An ISA device without an IO/MMIO capabilities seems extremely unlikely. What > exactly would such a device do? Inject interrupts via that bus (while exposing registers in some other way). The m48t59 seems to fall in this category (unless I'm missing something ATM). 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
