From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Automatic loading of xen-evtchn module in Xen 4.0.0? Date: Tue, 30 Mar 2010 15:47:12 -0700 Message-ID: <4BB27F70.4090703@goop.org> References: <20100327173221.GJ1878@reaktio.net> <4BAE8426.2050703@goop.org> <1269942297.10129.72385.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1269942297.10129.72385.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: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 03/30/2010 02:44 AM, Ian Campbell wrote: > On Sat, 2010-03-27 at 22:18 +0000, Jeremy Fitzhardinge wrote: > =20 >> On 03/27/2010 10:32 AM, Pasi K=C3=A4rkk=C3=A4inen wrote: >> =20 >>> Hello, >>> >>> xend automatically mounts /proc/xen, but it doesn't try loading evtch= n or xen-evtchn modules. >>> Should we add automatic loading of these modules? >>> >>> xend doesn't start if xen event channel functionality is missing. >>> >>> Fedora Xen rpms do load modules automatically, like this: >>> >>> # cat /etc/sysconfig/modules/xen.modules >>> #!/bin/sh >>> >>> test -d /proc/xen || exit 0 >>> test -f /proc/xen/capabilities || mount -t xenfs xen= /proc/xen >>> test -f /proc/xen/capabilities || exit 0 >>> grep -q "control_d" /proc/xen/capabilities || exit 0 >>> >>> for module in xen-evtchn evtchn blkbk netbk; do >>> modprobe ${module}>/dev/null 2>&1 >>> done >>> >>> =20 >> We should be able to make these mount automatically with udev rules, I >> think, but I'm not sure whether you can do udev rules to mount misc >> devices (which is what /dev/xen/evtchn is). >> =20 > I think you mean "modprobe misc devices" not mount. > =20 Yep. > I see various uses of the MODULE_ALIAS_MISCDEV macro in the kernel -- > but I'm not sure what actually causes a matching hotplug event to be > generated, other than trying to open a matching device node which with > udev won't exist until the module is loaded. > > Perhaps something in the xen core code (or xenbus?) could generate the > necessary hotplug events for the Xen "platform devices" (like the evtch= n > one)? > > =20 >> I think the front/back xenbus and device drivers are still a bit of a >> mess with regard to modules; I have to admit I tend to just compile th= em >> all in. It would be nice to get all that properly sorted out so they >> can be sensibly modularized and auto-loaded as required. (A good firs= t >> step would be to systematically work out what compile combinations >> actually work or fail, hint, hint ;) >> =20 > AFAIK the frontend driver modules work correctly as modules and distros > have been compiling them modular for a while (Debian certainly has). > =20 Yes, I think frontend drivers are OK. But the various xenbus bits seem=20 a bit fragile. > The situation is certainly not as rosy for *back. It'd certainly be nic= e > if some (or all) of the xenbus stuff could become modular too although = I > would guess there will be a core which must be compiled in. > =20 In practice there's no need to get very modular. There's some value in=20 not loading all that backend support code unless we're actually dom0,=20 but I don't think there's much value in getting too fine-grained beyond=20 that. The actual drivers themselves are fairly ordinary, so they will=20 probably just work if we can make xenbus generate the right request=20 events. Hm, I guess that would be the tool stack setting things up for=20 a new domain, and requesting backend devices in the process, no? But it doesn't help for things like evtchn and gntdev. But there's no=20 huge burden in just making the toolstack startup scripts do modprobes=20 for them, just as it should be mounting /proc/xen. J