Re: RFC qdev path semantics

[Markus Armbruster <armbru@redhat.com>]

Markus Armbruster <armbru@redhat.com> writes:

> A number of changes to qdev paths have been proposed in various threads.
> It's becoming harder to keep track of them, so let me sum them up in one
> place.  Please correct me if I misrepresent your ideas.
>
> I'm going to describe the current state of things, and the proposed
> changes (marked with ###).
>
>
> The device tree has the main system bus as root.  A child of a bus is a
> device.  A child of a device is a bus.
>
> A qdev path consists of qdev path components separated by '/'.  It
> resolves to a node in the device tree, either bus or device.
>
> The qdev path "/" resolves to the root, i.e. the main system bus.
>
> The qdev path IDENT, where IDENT is an identifier, resolves to the
> device whose id is IDENT.

Err, this is not what the current code does.  IDENT resolves to the
*bus* whose name is IDENT.  Device IDs don't come into play.  Yes, bus
names need not be globally unique.  We use whichever bus we find first.

We should really support device IDs as anchor of relative paths.  

As far as I can see, we don't currently support paths when we look for a
device, only device IDs.  But we'd like to change that.  Say we extend
device_del to accept a path, not just a device ID.  But how to interpret
an identifier argument then?  Backward compatibility and common sense
say it's a device ID.  But it's also a relative qdev path with just one
path component, a bus name.

What a mess!

> If PATH resolves to device DEV, and a child of DEV has the name IDENT,
> then we resolve to that bus.

then we resolve PATH/IDENT to that bus.

[...]