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

[Markus Armbruster <armbru@redhat.com>]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> Markus Armbruster wrote:
>> Paul Brook <paul@codesourcery.com> writes:
>> 
>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>
>>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>>> Could you explain why you add "identified properties of the immediate
>>>>> parent bus and device"?  They make the result ver much *not* a "dev
>>>>> path" in the qdev sense...
>>>> In order to try to get a unique string.  Without looking into device
>>>> properties, two e1000s would both be:
>>>>
>>>> /main-system-bus/pci.0/e1000
>>>> /main-system-bus/pci.0/e1000
>>>>
>>>> Which is no better than simply "e1000" and would require us to fall back
>>>> to instance ids again.  The goal here is that anything that makes use of
>>>> passing a dev when registering a vmstate gets an instance id of zero.
>>> You already got the information you need, you just put it in the wrong place. 
>>> The canonical ID for the device could be its bus address. In practice we'd 
>>> probably want to allow the user to specify it by name, provided these are 
>>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would 
>>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we 
>>> can use an initial prefix to disambiguate a name/label from a bus address.
>>>
>>> For busses that don't have a consistent addressing scheme then some sort of 
>>> instance ID is unavoidable. I guess it may be possible to invent something 
>>> based on other device properties (e.g. address of the first IO port/memory 
>>> region).
>> 
>> When that's inconvenient or impossible, we can still punt to user: make
>> device ID mandatory.
>
> No option due to auto-created devices. And auto-generating IDs would
> just create usability issues.

Auto-generated IDs would become part of the ABI.  Really so bad that
it's "no option"?  Mind, device ID becomes mandatory *only* for devices
that don't have a useful bus address.  We could even waive the ID
requirement for the first device of a kind, i.e. require ID if and only
if it's needed to disambiguate.

>> We obviously need a way to unambigously name a device.  It's okay to
>> have multiple names for the same device.
>> 
>> If the device has a device ID, that's an unambigous name.
>> 
>> qdev paths may be ambigous when path components are resolved to driver
>> names instead of IDs.
>> 
>> 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.

I'm not arguing against the use of driver names at all.

>> 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.

It's not either/or.  Addressing by ID continues to work.  Addressing by
bus/driver-name continues to work.  We merely add addressing by
bus/@bus-address.

>> 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.

I object to <driver>@<bus-address>, because the <driver> part carries no
information.

Not the case for <driver>.<instance-no>.  We still need a suitable
definition of <instance-no>.  Possible definitions:

* n-th creation of a <driver> device.  Drawbacks: depends on creation
  order.  Relatively hard to maintain across migration.

* n-th instance of a <driver> device.  Drawback: changes on unplug.
  Good enough for interactive use, but it doesn't provide a stable
  device name.

When counting <driver> devices either way, we can count per bus or
globally.  I prefer per bus.

None of the above instance numbers are nearly as neat as bus addresses.

>> 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.
>
> Jan