Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()

[Jan Kiszka <jan.kiszka@siemens.com>]

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