On Tue, 2010-03-30 at 15:22 +0100, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 30, 2010 at 10:44:57AM +0100, Ian Campbell wrote:
> > On Sat, 2010-03-27 at 22:18 +0000, Jeremy Fitzhardinge wrote:
> > > On 03/27/2010 10:32 AM, Pasi Kärkkäinen wrote:
> > > > Hello,
> > > >
> > > > xend automatically mounts /proc/xen, but it doesn't try loading evtchn
> > > > 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
> > > >
> > >
> > > 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).
> >
> > I think you mean "modprobe misc devices" not mount.
> >
> > 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.
>
> One idea that I submitted to dracut mailing list (the initramfs
> creation/running tool under FC12 and above) was to leverage 'xen-detect'
> and load the appropiate modules. This way during bootup, bamm, you get
> all your modules in.
>
> But they righly suggested that there should be an uevent to kick udev to
> start loading them and use the MODULE_ALIAS. But to use MODULE_ALIAS,
> you have to get an uevent, and to get an uevent, you have to load the
> module, so it looks to be a chicken-and-egg problem.
>
> >
> > Perhaps something in the xen core code (or xenbus?) could generate the
> > necessary hotplug events for the Xen "platform devices" (like the evtchn
> > one)?
>
> But I think that comes back to the chicken-and-egg. If you have all of
> the front-end drivers compiled as modules, how would they (front-end
> drivers) generate the hotplug events when they are not loaded?
The xenbus infrastructure sees e.g. the /vif/ node appear in xenstore
and generates an event for "xen:vif" which xen-netfront declares as an
alias so the module will be loaded.
In other words it is up to the _bus_ implementation not the drivers to
generate the events to cause the drivers to be loaded.
For frontend drivers this works today, AFAIK.
The issue with the evtchn driver is that there is no bus as such. We
could potentially make use of the existing platform device
infrastructure which is kind of like a bus for system devices which
aren't really on a bus.
I guess the xenbus driver itself falls into the same sort of category as
the evtchn driver.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home