From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Automatic loading of xen-evtchn module in Xen 4.0.0? Date: Wed, 31 Mar 2010 09:39:23 -0400 Message-ID: <20100331133923.GB28074@phenom.dumpdata.com> References: <20100327173221.GJ1878@reaktio.net> <4BAE8426.2050703@goop.org> <1269942297.10129.72385.camel@zakaz.uk.xensource.com> <4BB27F70.4090703@goop.org> <1270024840.10129.72471.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1270024840.10129.72471.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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//"). 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?