[Qemu-devel] Re: RFC qdev path semantics

[Alex Williamson]

I'm a little bit lost at how to implement something to print these
semantics, but a couple comments below...

On Wed, 2010-06-16 at 11:46 +0200, Markus Armbruster wrote:
> 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.
> 
> If PATH resolves to device DEV, and a child of DEV has the name IDENT,
> then we resolve to that bus.
> 
> Bus names are chosen by the system as follows:
> 
> * If the driver of the parent device model provides a name, use that.
> 
> * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
>   number, counting from zero in creation order.
> 
> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
>   is the bus number, as above.
> 
> ### Paul proposes to drop ID.NUM.
> 
> ### Paul proposes to either drop TYPE.NUM (and require drivers to
>     provide bus names), or make NUM count separately for each bus type.

I agree, instance numbers are not stable.  Would it be reasonable to
outlaw instance numbers of any kind for devices that are children of
buses with BusState.allow_hotplug == 1?

> If PATH resolves to bus BUS, then we resolve PATH/IDENT as follows:
> 
> * If a child of BUS has id IDENT, then we resolve to that device.
> 
>   ### Jan proposes to drop this rule.
> 
> * Else, if a child of BUS has a driver with name IDENT, then we resolve
>   to that device.
> 
>   If more than one exist, resolve to the first one.  This assumes
>   children are ordered.  Order is the same as in "info qtree".
>   Currently, it's reverse creation order.
> 
>   This is *not* a stable address.
> 
> * Else, if a child of BUS has a driver with alias name IDENT, then we
>   resolve to that device.
> 
>   If more than one exist, resolve to the first one.  This assumes
>   children are ordered.  Order is the same as in "info qtree".
>   Currently, it's reverse creation order.
> 
>   This is *not* a stable address.
> 
> ### I propose: we resolve PATH/@BUS-ADDR to the child of BUS with bus
>     address BUS-ADDR, if devices on this type of bus have bus addresses.
>     The format of BUS-ADDR depends on the bus.
> 
> ### Paul proposes to require all buses to define bus addresses.  Make
>     one up if necessary.

That seems arbitrary and prone to breakage.  How do we handle a subtle
change in device instantiation order and still allow migration?  If by
code change or command line ordering my frobnitz moves from:

/i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/0

to

/i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/1

and it has a vmstate or ramblock associated with it, how do we match
those up?

> ### Jan proposes: we resolve PATH/IDENT.NUM as follows:

This isn't stable.  Same as above.  I don't think we can allow this on
buses support hotplug.

>     * If a child of BUS has a driver with name IDENT and an instance
>       number NUM, then we resolve to that device.
> 
>       Need a suitable definition of "instance number".
> 
>       Jan proposes to number devices with the same driver on the same
>       bus.  This assumes children are ordered, see above.
> 
>       This is *not* a stable address if the bus supports hot-plug.
> 
>       I propose to us bus-address as instance number.  Works best
>       together with Paul's proposal to define bus addresses.  Syntax
>       address@hidden makes more sense then.
> 
>     * Else, same with driver alias name.
> 
> ### Here's a possible synthesis of the above three proposals: require
>     bus addresses, and permit any of
> 
>         PATH/IDENT
>         PATH/@BUS-ADDR
>         PATH/address@hidden
> 
>     PATH/IDENT can't address instances that don't come first.
> 
>     IDENT in PATH/address@hidden is redundant.  Therefore, it can't be
>     the canonical qdev path.  That's fine, PATH/@BUS-ADDR serves.

I can live with PATH/@BUS-ADDR if it's still felt that
PATH/address@hidden isn't canonical.  What that means is that I'll
probably code up vmstate and ramblocks to append IDENT themselves to
keep all the goodness of having per PATH/IDENT namespaces.  Do we want
to settle on a standard end of path delineation?  Should I use

PATH/@BUS-ADDR$IDENT.foo

?

Alex

> If the above rules resolve PATH to a device in a context where we expect
> a bus, and the device has exactly one bus, resolve it to that bus
> instead.
> 
> ### Jan and I propose to drop this rule.