Re: [PATCH] tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start

[Olaf Hering <olaf@aepfle.de>]

On Wed, Aug 08, Jan Beulich wrote:

> >>> On 07.08.12 at 19:22, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> >> Jan Beulich writes ("Re: [Xen-devel] [PATCH] tools/hotplug/Linux/init.d/: 
> >> - not exclusively try the pv-ops kernel's module names.
> > 
> > Do you mean that 4.2 should try loading some bigger set of module
> > names ?  If so then do you have a list ? :-)
> 
> - xen-blkback's counterpart is blkbk
> - xen-netback's counterpart is netbk
> 
> xen-evtchn/evtchn and xen-gntdev/gntdev are already taken
> care of, albeit in a little strange a way (the two entries being
> separated by an increasing amount of other ones, when it is
> really pointless to load the second one if the first one's load
> succeeded).
> 
> To not needlessly try everything, it might additionally be worth
> a thought to
> - first try loading via module alias rather than module name (if
>   that succeeds for a carefully chosen module that got its alias
>   added late - according to our patches, the devname: aliases
>   got introduced in 2.6.35, and the xen-backend: ones in 3.1 -,
>   only try loading via module alias for all subsequent ones)
> - second try loading a (or all) pvops named module(s) (if that/
>   any of them succeed(s), there's no need to try _any_ non-
>   pvops names subsequently, i.e. including ones that don't even
>   exist in the legacy trees)
> - last try loading the traditional/forward-port named ones

I think it can be done like this because I'm sure that the xenlinux
based dom0 kernels have the drivers compiled as modules. So if evtchn.ko
exists its xenlinux based, otherwise its pvops. I havent runtime tested
that patch yet.

Olaf

diff -r 7ce01c435f5a tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -50,18 +50,39 @@ if test -f /proc/xen/capabilities && \
 	exit 0
 fi
 
+# Load all drivers in a xenlinux based dom0
+do_modprobe_xenlinux() {
+	for mod in gntdev netbk blkbk xen-scsibk usbbk tpmbk pciback
+	do
+		modprobe ${mod} 2>/dev/null
+	done
+}
+
+# Load all drivers in a pvops based dom0
+do_modprobe_pvops() {
+	for mod in evtchn gntdev gntalloc acpi-processor
+	do
+		modprobe xen-${mod} 2>/dev/null
+	done
+	for be in vbd vif pci
+	do
+		modprobe xen-backend:${be} 2>/dev/null
+	done
+}
+
 do_start () {
         local time=0
 	local timeout=30
 
-	modprobe xen-evtchn 2>/dev/null
-	modprobe xen-gntdev 2>/dev/null
-	modprobe xen-gntalloc 2>/dev/null
-	modprobe xen-blkback 2>/dev/null
-	modprobe xen-netback 2>/dev/null
-	modprobe evtchn 2>/dev/null
-	modprobe gntdev 2>/dev/null
-	modprobe xen-acpi-processor 2>/dev/null
+	# Check if dom0 is based on xenlinux, its drivers are all modules
+	# If loading succeeds assume its xenlinux based, otherwise its pvops based
+	if modprobe evtchn 2>/dev/null
+	then
+		do_modprobe_xenlinux
+	else
+		do_modprobe_pvops
+	fi
+
 	mkdir -p /var/run/xen
 
 	if ! `xenstore-read -s / >/dev/null 2>&1`