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

Markus Armbruster
2010-06-15T13:17:02Z

Jan Kiszka <jan.kiszka@siemens.com> 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.