On Thu, Nov 02, 2006 at 04:02:48PM +0100, Markus Armbruster wrote:
> Ewan Mellor <ewan@xxxxxxxxxxxxx> writes:
>
> > On Thu, Nov 02, 2006 at 11:10:12AM +0100, Markus Armbruster wrote:
> >
> >> I'm now looking into a conversion to xenbus_driver API. I started
> >> with copying some voodoo from blkfront.c. My
> >> xenbus_register_frontend() succeeds. Stupid question: what triggers
> >> running of the probe function? Because mine doesn't.
> >
> > Either the watch firing when the correct entries in the store are written
> > (for
> > hotplugging) or it probes those paths at startup.
> >
> > xenbus/xenbus_probe.c:
> >
> > frontend_changed ->
> > dev_changed ->
> > xenbus_probe_node ->
> > device_register
> >
> > or
> >
> > xenbus_probe_init ->
> > xenbus_probe ->
> > xenbus_probe_devices ->
> > xenbus_probe_device_type ->
> > bus->probe ->
> > xenbus_probe_frontend ->
> > xenbus_probe_node ->
> > device_register
> >
> > The device_register causes a the specific frontend device to be registered,
> > which triggers the probe.
>
> Err, I still don't get it. What exactly makes the guest run the
> frontend's probe? I figure you're trying to tell me that it runs when
> a certain xenstore entry is present at startup, or when it gets
> created later. Corrrect? Which entry exactly? I tried a few (more
> voodoo), but no luck.
/local/domain/<domid>/device/<devclass>/<devid>
<devclass> is the string that you've put in xenbus_driver.name when
registering it with xenbus_register_frontend. The xenbus driver registers a
watch on /local/domain/<domid>/device, and whenever that fires, dev_changed
looks through the registered drivers, looking for the one with the right
<devclass>, and it all gets kicked off from there.
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home