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

[Paul Brook]

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

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

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

Paul