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

[Paul Brook <paul@codesourcery.com>]

> On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> > > > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
> > 
> > There's a device missing between the main system bus and the pci bus. 
> > Should be something like:
> > 
> > /main-system-bus/piix4-pcihost/pci.0/_09.0
> 
> Ok, I can easily come up with:
> 
> /System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virti
> o-blk

No. Now you've got way to many elements in the path.  My point is that you 
replace the name of the device with the bus address of the device.

However you determine the element names the path should be /busname/devicename 
pairs. I'm undecided whether the root element should be the main system bus, 
or a system device node that contains the main system bus.

> > 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.
> 
> Sure, if there was a guaranteed unique char* on a DeviceState that was
> consistent between guest invocations, we could just use that instead.  I
> suppose all devices could have a global system id property and if that
> was present we'd use that instead of creating the device path.

All we require is some way of uniquely addressing each device on the bus. For 
PCI that's trivial (devfn). For other busses we get to pick something 
appropriate.
 
> > Device names have a restricted namespace, so we
> > can use an initial prefix to disambiguate a name/label from a bus
> > address.
> 
> I'm not sure it's necessary.  It seems like it would only be necessary
> to differentiate the two if we wanted to translate between namespaces.
> But I think it's reasonable to require that if a global name is
> provided, it must always be provided for the life of the VM.

I don't think requiring that all devices are given a globally unique name is 
going to fly. locally (per-bus) unique user-specified are still a PITA, but 
may be acceptable. Having a canonical addressing system that's independent of 
user assigned IDs seems like a good thing.

> > 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).
> 
> Instance IDs aren't always bad, we just run into trouble with hotplug
> and maybe creating unique ramblock names.  But, such busses typically
> don't support hotplug and don't have multiple instances of the same
> device on the bus, so I don't expect us to hit many issues there as long
> as we can get a stable address path.  Thanks,

Simple consecutive instance IDs are inherently unstable. They depend on teh 
order of device creation. The ID really wants to be something that can be 
reliably determined from the device bus itself (and/or its interaction with 
its parent bus).

Paul