[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Automatic loading of xen-evtchn module in Xen 4.0.0?



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.