Re: [Qemu-devel] [RFC 4/8] qdev: link based hotplug

[Igor Mammedov <imammedo@redhat.com>]

On Thu, 20 Mar 2014 19:03:57 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:

> Il 20/03/2014 17:20, Igor Mammedov ha scritto:
> >> >
> >> > What about just looking up on the QOM tree until you find a
> >> > HotplugHandler, if the device doesn't have a bus or the bus doesn't have
> >> > a hotplug handler link itself?  This is similar to how FWPathProvider works.
> > it does so "hotplug_handler_get_from_path()",
> > above just provides option to specify lookup path. See 6/8 where PC board
> > allocates links and sets its own board specific path for generic DimmDevice.
> 
> Yeah, but I'm not sure why you need the links.  Why can't you just start 
> from the canonical path, such as /machine/peripheral/dimm-0 for -device 
> dimm,id=dimm-0, and walk up from there?
That would work in this particular case since /machine is hotplug handler,
but in generic case hotplug handler can be located somewhere else in QOM tree
i.e. it isn't a parent of hotplugged device.

Allowing to customize lookup path via DeviceClass.hotplug_path() makes
wiring hotplug handler flexible. For example:
 * A target that decides to use DimmDevice cloud have hotplug handler
   located at /machine/peripheral/ec_foo, walking down from
   /machine/peripheral/dimm-0 or /machine/unassigned/dimm-0 (in hotplug case)
   won't allow to find  hotplug handler. But overriding DeviceClass.hotplug_path()
   the target machine could provide means to locate necessary hotplug handler

Maybe setting link<> is over-engineered and should be dropped for now,
while still keeping DeviceClass.hotplug_path() as a means to provide custom
hotplug hander path.


BTW not related to hotplug but why I used link<>s:

I've added link<>s as an attempt to visualize Andreas' idea to use them for
hotplug and mgmt. It has it's own benefits if we try to provide more or
less uniform QOM interface view for management. What I have in mind is that
we could have tree like this:
 /machine/node[...]/dimm[...]
                   /cpu[...]/core[...]/thread[...]

where leaves are link<>s which are prebuilt at startup and set when device
is added. It provides an easy to enumerate interface for mgmt and also
gives us a quite informative path that encodes topology and later
we could use it instead of custom properties. For example:

  device_add x86cpu,path=/machine/node[1]/cpu[0]/core[3]/thread[2]
vs
  device_add x86cpu,apic-id=[who knows how it's calculated]

or
  device_add dimm,path=/machine/node[0]/dimm[5]
vs
  device_add dimm,node=0,slot=5

i.e. being added device could decode all needed information from above
provided path instead of creating a bunch of custom properties.

> 
> Paolo