tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start
PATCH 1/1 tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start
# HG changeset patch
# User Fabio Fantoni
# Date 1338467204 -7200
# Node ID 1f57503f10112718ecbbe424fa8fc9c55785f4c0
# Parent dd7319230f4ac295b6d14ce2e2a3dccf82bb87d8 tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start
tools/hotplug/Linux/init.d/xencommons gio mag 31 14:26:44 2012 +0200 renamed from tools/hotplug/Linux/init.d/xencommons mer mag 23 12:27:26 2012 +0200 +3 -0
@@ -56,6 +56,9 @@ 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
# HG changeset patch
# User Fabio Fantoni
# Date 1338467204 -7200
# Node ID 1f57503f10112718ecbbe424fa8fc9c55785f4c0
# Parent dd7319230f4ac295b6d14ce2e2a3dccf82bb87d8 tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start
tools/hotplug/Linux/init.d/xencommons +3 -0
@@ -56,6 +56,9 @@ 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
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Fabio Fantoni writes ("[Xen-devel] [PATCH] tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start"):
Quoted 7 lines
# HG changeset patch
# User Fabio Fantoni
# Date 1338467204 -7200
# Node ID1f57503f10112718ecbbe424fa8fc9c55785f4c0
# Parentdd7319230f4ac295b6d14ce2e2a3dccf82bb87d8tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start
This looks at least harmless to me.
I'm surprised, however, that these things aren't loaded automatically. For example, shouldn't the xenbus driver's enumeration automatically load blkback too ?
Having said that, I'm inclined to apply this unless someone explains that it's a bad idea.
Ian.
Il 08/06/2012 16:07, Ian Jackson ha scritto:
Quoted 17 lines
Fabio Fantoni writes ("[Xen-devel] [PATCH]
tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start"):Quoted 7 lines
# HG changeset patch
# User Fabio Fantoni
# Date 1338467204 -7200
# Node ID1f57503f10112718ecbbe424fa8fc9c55785f4c0
# Parentdd7319230f4ac295b6d14ce2e2a3dccf82bb87d8tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons startThis looks at least harmless to me.
I'm surprised, however, that these things aren't loaded automatically. For example, shouldn't the xenbus driver's enumeration automatically load blkback too ?
Having said that, I'm inclined to apply this unless someone explains that it's a bad idea.
Quoted 9 lines
Ian.
-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2177 / Database dei virus: 2433/5056 - Data di rilascio: 08/06/2012
I have noticed that this patch wasn't commited, is there some problem with it?
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Quoted 9 lines · Ian Jackson
Fabio Fantoni writes ("[Xen-devel] [PATCH]
tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start"):Quoted 7 lines
# HG changeset patch
# User Fabio Fantoni
# Date 1338467204 -7200
# Node ID1f57503f10112718ecbbe424fa8fc9c55785f4c0
# Parentdd7319230f4ac295b6d14ce2e2a3dccf82bb87d8tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start
Quoted 5 lines
This looks at least harmless to me.
I'm surprised, however, that these things aren't loaded automatically. For example, shouldn't the xenbus driver's enumeration automatically load blkback too ?
Yes it should, there is autoloading stuff for all the backends.
Not sure about gntalloc. I suspect not.
Quoted 10 lines
Having said that, I'm inclined to apply this unless someone explains that it's a bad idea.
Ian.
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start"):
Quoted 7 lines · Ian Jackson
Quoted 6 lines
Fabio Fantoni writes ("[Xen-devel] [PATCH]
tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start"):Quoted 2 lines
tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons startThis looks at least harmless to me.
Quoted 10 lines
Quoted 3 lines
I'm surprised, however, that these things aren't loaded automatically. For example, shouldn't the xenbus driver's enumeration automatically load blkback too ?
Yes it should, there is autoloading stuff for all the backends.
Not sure about gntalloc. I suspect not.
Quoted 2 lines
Having said that, I'm inclined to apply this unless someone explains that it's a bad idea.
I have applied it.
But we should still try to fix the upstream kernels not to need it.
Thanks,
Ian.
Quoted 17 lines
Quoted 1 line
Quoted 1 line · Ian Jackson
Ian Campbell writes ("Re: [Xen-devel] [PATCH]
tools/hotplug/Linux/init.d/:
added other xen kernel modules on xencommons start"):Quoted 2 lines · Ian Jackson
Quoted 1 line
Fabio Fantoni writes ("[Xen-devel] [PATCH]
tools/hotplug/Linux/init.d/:added other xen kernel modules on xencommons start"):
Quoted 11 lines
Quoted 8 lines
Quoted 2 lines
tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons startThis looks at least harmless to me.
I'm surprised, however, that these things aren't loaded automatically. For example, shouldn't the xenbus driver's enumeration automatically load blkback too ?
Yes it should, there is autoloading stuff for all the backends.
Quoted 8 lines
Quoted 4 lines
Not sure about gntalloc. I suspect not.
Quoted 2 lines
Having said that, I'm inclined to apply this unless someone explains that it's a bad idea.
I have applied it.
But we should still try to fix the upstream kernels not to need it.
And just like for the respective pending blktap item, it should
- be made sure this gets backed out again after 4.2, making sure the loading happens either automatically or when the module is in fact needed, and
- not exclusively try the pv-ops kernel's module names.
Jan
Jan Beulich writes ("Re: [Xen-devel] [PATCH] tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start"):
Quoted 7 lines · Ian Jackson
Quoted 1 line
But we should still try to fix the upstream kernels not to need it.
And just like for the respective pending blktap item, it should
- be made sure this gets backed out again after 4.2, making sure the loading happens either automatically or when the module is in fact needed, and
Please do remind us :-).
Quoted 1 line
- 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 ? :-)
Ian.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line · Ian Jackson
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 notice, however, that in pvops no devname: module aliases exist - is that an oversight, Konrad? While for misc devices with dynamic minors these don't help with autoloading, they do help with abstracting away the module name as would be desirable here (and later in the tools, when they get to load the modules).
Bottom line is - for the recently (c/s 25728:a6edbc39fc84) added backend modules the above outlined scheme should work, while for the infrastructure ones step 1 should be skipped.
Jan
Quoted 16 lines · Jan Beulich
Quoted 6 lines
Quoted 3 lines
Quoted 1 line · Ian Jackson
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 netbkxen-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).
Quoted 12 lines
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
tools/hotplug/Linux/init.d/xencommons +29 -8
@@ -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`
Quoted 32 lines
Quoted 1 line
Quoted 1 line · Olaf Hering
Quoted 16 lines · Jan Beulich
Quoted 6 lines
Quoted 3 lines
Quoted 1 line · Ian Jackson
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 netbkxen-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).
Quoted 12 lines
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
Quoted 4 lines
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.
That's the case for our kernels, but doesn't have to be for any derived ones (and there are still a few people cloning our patches).
Jan
Quoted 2 lines · Jan Beulich
That's the case for our kernels, but doesn't have to be for any derived ones (and there are still a few people cloning our patches).
Do they build things into the kernel?
Should some other module than evtchn be used to decide which branch to take?
Olaf
Quoted 9 lines
Quoted 1 line
Quoted 1 line · Olaf Hering
Quoted 2 lines · Jan Beulich
That's the case for our kernels, but doesn't have to be for any derived ones (and there are still a few people cloning our patches).
Do they build things into the kernel?
Should some other module than evtchn be used to decide which branch to take?
There are people who build in everything. So you would only ever be able to derive results from being able to load some specific module; not being able to load a certain module doesn't allow drawing any conclusion.
Jan
Quoted 6 lines · Jan Beulich
Quoted 6 lines
Quoted 1 line
Quoted 1 line · Olaf Hering
Quoted 2 lines · Jan Beulich
That's the case for our kernels, but doesn't have to be for any derived ones (and there are still a few people cloning our patches).
Quoted 8 lines
Quoted 3 lines
Do they build things into the kernel?
Should some other module than evtchn be used to decide which branch to take?There are people who build in everything. So you would only ever be able to derive results from being able to load some specific module; not being able to load a certain module doesn't allow drawing any conclusion.
If attempting to load pvops modules in a xenlinux based kernel is an issue then there needs to be another way to tell them appart. A lame test would be test -f /proc/xen/balloon which doesnt seem to exist in pvops dom0.
If attempting to load non-existant modules is not an issue then I will prepare a patch which adds "netbk blkbk xen-scsibk usbbk pciback" to the list.
Olaf
Olaf Hering writes ("Re: [Xen-devel] [PATCH] tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start"):
Quoted 3 lines
If attempting to load non-existant modules is not an issue then I will prepare a patch which adds "netbk blkbk xen-scsibk usbbk pciback" to the list.
The existing scattershot list of modprobes is based on the assumption that loading non-existent modules is harmless. So yes please.
Thanks,
Ian.
Olaf Hering writes ("Re: [Xen-devel] [PATCH] tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start"):
Quoted 4 lines
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.
I was under the impression that there is no harm in attempting to load nonexistent modules. So it would surely be better just to expand the list that we try.
Ian.