On Wed, Mar 31, 2010 at 09:40:40AM +0100, Ian Campbell wrote:
> On Tue, 2010-03-30 at 23:47 +0100, Jeremy Fitzhardinge wrote:
> >
> > In practice there's no need to get very modular. There's some value
> > in
> > not loading all that backend support code unless we're actually dom0,
> > but I don't think there's much value in getting too fine-grained
> > beyond that. The actual drivers themselves are fairly ordinary, so
> > they will probably just work if we can make xenbus generate the right
> > request events. Hm, I guess that would be the tool stack setting
> > things up for a new domain, and requesting backend devices in the
> > process, no?
>
> What happens with frontend hotplug, and should happen with backends too,
> is that the xenbus core watches the "device" (or "backend") node in
> xenstore (relative to the domain's root path "/local/domain/<X>/"). The
> tools then create the necessary nodes to create the device which
> triggers the xenstore watch, e.g. on a path starting with "vif", which
> causes xenbus to generate a uevent with the necessary MODALIAS, see
> drivers/xen/xenbus/xenbus_probe.c:xenbus_uevent().
>
> The only problem with this is getting the initial xenbus-backend.ko
> loaded so that it can do the watch -- perhaps that falls in the same
> boat as evtchn and gntdev etc.
.. which goes back to what I suggested some time ago, that might do the
trick. That is to make the owner of /sys/hypervisor do a kobject_uevent
and have an udev rule that would listen to this and load the
xenbus-backend.ko. That should start the avalanche of Xen backend module
loading, I think?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home