[dracut] Loading of modules that don't have a uevent or pci device: ideas?

[dracut] Loading of modules that don't have a uevent or pci device: ideas?

[Konrad Rzeszutek Wilk]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

Hey Harald and initramfs mailing list, 

I am working on de-coupling a lot of Xen modules from the PV-OPS
kernel (git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git)
so that it is not neccessary to have them compiled in.

I've gotten to the point that all of the drivers (fbfront, kbdfront,
netfront, blkfront, pcifront) can be loaded on demand. Some of them
can't be unloaded (still working on that).

The next stage is to make the loading automatic, and detect if the kernel
is running under Xen (PV) and if so load the neccesssary modules.

To solve that, my thought was to:

a) Write udev rules that would be act up if the kernel emitted such
rules. But the kernel does not emit any uevents for this purpose and
it does not emit any virtualization ones until the virtualization modules
are loaded.  I could write up code that would emit this
information and be generic enough that it would do so for anything
that uses the paravirt strutures. So basically a SysFS interface for
the paravirt interface. 

b) Or utilize xen-detect and load the appropiate modules if we are
running in Xen PV land. The second is by far much simpler but I don't
know if more appropiate. I am attaching an example patch to demonstrate
what I had in mind. (Caveat: I didn't include the pre-requisite for
xen-tools yet).

c). Another way? Any ideas would be much appreciated.


[-- Attachment #2: dracut_xen_support.patch --]
[-- Type: text/plain, Size: 2720 bytes --]

diff -uNpr dracut-003.orig/dracut.spec dracut-003/dracut.spec
--- dracut-003.orig/dracut.spec	2009-12-21 15:41:45.574109292 -0500
+++ dracut-003/dracut.spec	2009-12-21 16:02:09.019109359 -0500
@@ -162,6 +162,7 @@ rm -rf $RPM_BUILD_ROOT
 %{_datadir}/dracut/modules.d/10redhat-i18n
 %{_datadir}/dracut/modules.d/10rpmversion
 %{_datadir}/dracut/modules.d/50plymouth
+%{_datadir}/dracut/modules.d/60xen
 %{_datadir}/dracut/modules.d/90crypt
 %{_datadir}/dracut/modules.d/90dm
 %{_datadir}/dracut/modules.d/90dmraid
@@ -216,6 +217,9 @@ rm -rf $RPM_BUILD_ROOT
 %dir /var/lib/dracut/overlay
 
 %changelog
+* Mon Dec 21 2009 Konrad Rzeszutek Wilk <konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 003
+- add support for loading Xen modules.
+
 * Mon Nov 23 2009 Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 002-26
 - add WITH_SWITCH_ROOT make flag
 - add fips requirement conditional
diff -uNpr dracut-003.orig/modules.d/60xen/check dracut-003/modules.d/60xen/check
--- dracut-003.orig/modules.d/60xen/check	1969-12-31 19:00:00.000000000 -0500
+++ dracut-003/modules.d/60xen/check	2009-12-21 16:26:35.754120140 -0500
@@ -0,0 +1,12 @@
+#!/bin/bash
+
+# No Xen-detect? Boo!!
+which xen-detect >/dev/null 2>&1 || exit 1
+
+. $dracutfunctions
+[[ $debug ]] && set -x
+
+# Yes, we are under Xen PV env.
+xen-detect | egrep -q -v 'PV' || exit 0
+
+exit 1
diff -uNpr dracut-003.orig/modules.d/60xen/install dracut-003/modules.d/60xen/install
--- dracut-003.orig/modules.d/60xen/install	1969-12-31 19:00:00.000000000 -0500
+++ dracut-003/modules.d/60xen/install	2009-12-21 15:57:08.243111382 -0500
@@ -0,0 +1,4 @@
+#!/bin/bash
+inst xen-detect 
+inst_hook pre-udev 40 "$moddir/xen-pre-udev.sh"
+
diff -uNpr dracut-003.orig/modules.d/60xen/installkernel dracut-003/modules.d/60xen/installkernel
--- dracut-003.orig/modules.d/60xen/installkernel	1969-12-31 19:00:00.000000000 -0500
+++ dracut-003/modules.d/60xen/installkernel	2009-12-21 16:00:08.388121268 -0500
@@ -0,0 +1,9 @@
+#!/bin/bash
+
+for i in \
+    xenbus_probe_frontend xen-pcifront \
+    xen-fbfront xen-kbdfront xen-blkfront xen-netfront \
+    ; do
+    modinfo -k $kernel $i >/dev/null 2>&1 && instmods $i
+done
+
diff -uNpr dracut-003.orig/modules.d/60xen/xen-pre-udev.sh dracut-003/modules.d/60xen/xen-pre-udev.sh
--- dracut-003.orig/modules.d/60xen/xen-pre-udev.sh	1969-12-31 19:00:00.000000000 -0500
+++ dracut-003/modules.d/60xen/xen-pre-udev.sh	2009-12-21 16:03:52.735120719 -0500
@@ -0,0 +1,10 @@
+xen-detect
+RC=$?
+if [ "$RC" = "1" ] ; then
+        modprobe xenbus_probe_frontend
+        modprobe xen-kbdfront
+        modprobe xen-fbfront
+        modprobe xen-blkfront
+        modprobe xen-netfront
+        modprobe xen-pcifront
+fi

Re: [dracut] Loading of modules that don't have a uevent or pci device: ideas?

[Harald Hoyer]

On 12/21/2009 10:26 PM, Konrad Rzeszutek Wilk wrote:
> Hey Harald and initramfs mailing list,
>
> I am working on de-coupling a lot of Xen modules from the PV-OPS
> kernel (git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git)
> so that it is not neccessary to have them compiled in.
>
> I've gotten to the point that all of the drivers (fbfront, kbdfront,
> netfront, blkfront, pcifront) can be loaded on demand. Some of them
> can't be unloaded (still working on that).
>
> The next stage is to make the loading automatic, and detect if the kernel
> is running under Xen (PV) and if so load the neccesssary modules.
>
> To solve that, my thought was to:
>
> a) Write udev rules that would be act up if the kernel emitted such
> rules. But the kernel does not emit any uevents for this purpose and
> it does not emit any virtualization ones until the virtualization modules
> are loaded.  I could write up code that would emit this
> information and be generic enough that it would do so for anything
> that uses the paravirt strutures. So basically a SysFS interface for
> the paravirt interface.
>
> b) Or utilize xen-detect and load the appropiate modules if we are
> running in Xen PV land. The second is by far much simpler but I don't
> know if more appropiate. I am attaching an example patch to demonstrate
> what I had in mind. (Caveat: I didn't include the pre-requisite for
> xen-tools yet).
>
> c). Another way? Any ideas would be much appreciated.
>

I would favor "modalias" files in /sys, which will be used to modprobe the 
modules with the modalias.
Have a look at this:
$ find /sys -name modalias

I am sure this could be automated in the kernel without the need of extra 
special xen handling with scripts.

> +xen-detect
> +RC=$?
> +if [ "$RC" = "1" ] ; then

why not?

if xen-detect ; then ...; fi

Re: [dracut] Loading of modules that don't have a uevent or pci device: ideas?

[Konrad Rzeszutek Wilk]

On Tue, Dec 22, 2009 at 03:28:47PM +0100, Harald Hoyer wrote:
> On 12/21/2009 10:26 PM, Konrad Rzeszutek Wilk wrote:
>> Hey Harald and initramfs mailing list,
>>
>> I am working on de-coupling a lot of Xen modules from the PV-OPS
>> kernel (git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git)
>> so that it is not neccessary to have them compiled in.
>>
>> I've gotten to the point that all of the drivers (fbfront, kbdfront,
>> netfront, blkfront, pcifront) can be loaded on demand. Some of them
>> can't be unloaded (still working on that).
>>
>> The next stage is to make the loading automatic, and detect if the kernel
>> is running under Xen (PV) and if so load the neccesssary modules.
>>
>> To solve that, my thought was to:
>>
>> a) Write udev rules that would be act up if the kernel emitted such
>> rules. But the kernel does not emit any uevents for this purpose and
>> it does not emit any virtualization ones until the virtualization modules
>> are loaded.  I could write up code that would emit this
>> information and be generic enough that it would do so for anything
>> that uses the paravirt strutures. So basically a SysFS interface for
>> the paravirt interface.
>>
>> b) Or utilize xen-detect and load the appropiate modules if we are
>> running in Xen PV land. The second is by far much simpler but I don't
>> know if more appropiate. I am attaching an example patch to demonstrate
>> what I had in mind. (Caveat: I didn't include the pre-requisite for
>> xen-tools yet).
>>
>> c). Another way? Any ideas would be much appreciated.
>>
>
> I would favor "modalias" files in /sys, which will be used to modprobe 
> the modules with the modalias.
> Have a look at this:
> $ find /sys -name modalias

I think I did not explain the problem quite well. The modalias values
appear after the modules have been loaded. I am at the situation where I am
trying to figure out if I should load the modules or not - so the modalias
values are not present.

The one option that exists right now to detect whether we are running
under Xen is to use 'xen-detect', which I think you are OK with?

>
> I am sure this could be automated in the kernel without the need of extra 
> special xen handling with scripts.
>
>> +xen-detect
>> +RC=$?
>> +if [ "$RC" = "1" ] ; then
>
> why not?
>
> if xen-detect ; then ...; fi

Ooh, the patches I've for xen-detect return three different return values.
1 for PV Xen, 2 for HVM Xen, and 0 if no Xen.

Also xen-detect prints this out (depending on the scenario):

Running in HVM context on Xen v4.0.
Running in PV context on Xen v4.0.
Not running on Xen.

And it looks that 'if xen-detect', the if clause takes under consideration
the output - which means that on machines not running Xen it would still jump in the
"then" clause.

I think I am going to modify the xen-detect to accept another flag that would
just print a string if it is running in a PV context and nothing else- that
should make it easier.

Re: [dracut] Loading of modules that don't have a uevent or pci device: ideas?

[Hannes Reinecke]

Hi Konrad,

Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 22, 2009 at 03:28:47PM +0100, Harald Hoyer wrote:
>> On 12/21/2009 10:26 PM, Konrad Rzeszutek Wilk wrote:
>>> Hey Harald and initramfs mailing list,
>>>
>>> I am working on de-coupling a lot of Xen modules from the PV-OPS
>>> kernel (git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git)
>>> so that it is not neccessary to have them compiled in.
>>>
>>> I've gotten to the point that all of the drivers (fbfront, kbdfront,
>>> netfront, blkfront, pcifront) can be loaded on demand. Some of them
>>> can't be unloaded (still working on that).
>>>
>>> The next stage is to make the loading automatic, and detect if the kernel
>>> is running under Xen (PV) and if so load the neccesssary modules.
>>>
>>> To solve that, my thought was to:
>>>
>>> a) Write udev rules that would be act up if the kernel emitted such
>>> rules. But the kernel does not emit any uevents for this purpose and
>>> it does not emit any virtualization ones until the virtualization modules
>>> are loaded.  I could write up code that would emit this
>>> information and be generic enough that it would do so for anything
>>> that uses the paravirt strutures. So basically a SysFS interface for
>>> the paravirt interface.
>>>
>>> b) Or utilize xen-detect and load the appropiate modules if we are
>>> running in Xen PV land. The second is by far much simpler but I don't
>>> know if more appropiate. I am attaching an example patch to demonstrate
>>> what I had in mind. (Caveat: I didn't include the pre-requisite for
>>> xen-tools yet).
>>>
>>> c). Another way? Any ideas would be much appreciated.
>>>
>> I would favor "modalias" files in /sys, which will be used to modprobe 
>> the modules with the modalias.
>> Have a look at this:
>> $ find /sys -name modalias
> 
> I think I did not explain the problem quite well. The modalias values
> appear after the modules have been loaded. I am at the situation where I am
> trying to figure out if I should load the modules or not - so the modalias
> values are not present.
> 
D'oh.

But that's exactly the wrong way round.
The sole reason for having a modalias attribute (in the device) is to facilitate
module autoloading.
If the modalias attribute appears _after_ the module has been loaded you might
want to redesign the module ...

> The one option that exists right now to detect whether we are running
> under Xen is to use 'xen-detect', which I think you are OK with?
> 
>> I am sure this could be automated in the kernel without the need of extra 
>> special xen handling with scripts.
>>
>>> +xen-detect
>>> +RC=$?
>>> +if [ "$RC" = "1" ] ; then
>> why not?
>>
>> if xen-detect ; then ...; fi
> 
> Ooh, the patches I've for xen-detect return three different return values.
> 1 for PV Xen, 2 for HVM Xen, and 0 if no Xen.
> 
> Also xen-detect prints this out (depending on the scenario):
> 
> Running in HVM context on Xen v4.0.
> Running in PV context on Xen v4.0.
> Not running on Xen.
> 
> And it looks that 'if xen-detect', the if clause takes under consideration
> the output - which means that on machines not running Xen it would still jump in the
> "then" clause.
> 
> I think I am going to modify the xen-detect to accept another flag that would
> just print a string if it is running in a PV context and nothing else- that
> should make it easier.

Easiest bit would be if there were some bits of (virtual) devices, to which the Xen
drivers could attach to. Doesn't Xen already provide something here?

What does xen-detect do?
If it's just looking at some sysfs attributes then we can easily build up a udev rule.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: [dracut] Loading of modules that don't have a uevent or pci device: ideas?

[Luca Berra]

On Mon, Jan 11, 2010 at 04:40:14PM +0100, Hannes Reinecke wrote:
>
>Konrad Rzeszutek Wilk wrote:
>>>> b) Or utilize xen-detect and load the appropiate modules if we are
>>>> running in Xen PV land. The second is by far much simpler but I don't
>>>> know if more appropiate. I am attaching an example patch to demonstrate
>>>> what I had in mind. (Caveat: I didn't include the pre-requisite for
>>>> xen-tools yet).
>>>>
>>>> c). Another way? Any ideas would be much appreciated.
>>>>
>>> I would favor "modalias" files in /sys, which will be used to modprobe 
>>> the modules with the modalias.
>>> Have a look at this:
>>> $ find /sys -name modalias
>> 
>> I think I did not explain the problem quite well. The modalias values
>> appear after the modules have been loaded. I am at the situation where I am
>> trying to figure out if I should load the modules or not - so the modalias
>> values are not present.
>> 
>D'oh.
>
>But that's exactly the wrong way round.
>The sole reason for having a modalias attribute (in the device) is to facilitate
>module autoloading.
>If the modalias attribute appears _after_ the module has been loaded you might
>want to redesign the module ...

Actually the whole module directory appears _after_ the module is
loaded.

>> The one option that exists right now to detect whether we are running
>> under Xen is to use 'xen-detect', which I think you are OK with?
>> 
>>> I am sure this could be automated in the kernel without the need of extra 
>>> special xen handling with scripts.
>>>
>>>> +xen-detect
>>>> +RC=$?
>>>> +if [ "$RC" = "1" ] ; then
>>> why not?
>>>
>>> if xen-detect ; then ...; fi
>> 
>> Ooh, the patches I've for xen-detect return three different return values.
>> 1 for PV Xen, 2 for HVM Xen, and 0 if no Xen.
>> 
>> Also xen-detect prints this out (depending on the scenario):
>> 
>> Running in HVM context on Xen v4.0.
>> Running in PV context on Xen v4.0.
>> Not running on Xen.
>> 
>> And it looks that 'if xen-detect', the if clause takes under consideration
>> the output - which means that on machines not running Xen it would still jump in the
>> "then" clause.

"if xen-detect" looks at the return code of xen-detect
so it should be
if ! xen-detect; then echo we are running xen;else echo no xen;done

>> I think I am going to modify the xen-detect to accept another flag that would
>> just print a string if it is running in a PV context and nothing else- that
>> should make it easier.
Please don't. return code are much better to parse than text strings

>Easiest bit would be if there were some bits of (virtual) devices, to which the Xen
>drivers could attach to. Doesn't Xen already provide something here?
>
>What does xen-detect do?
>If it's just looking at some sysfs attributes then we can easily build up a udev rule.



-- 
Luca Berra -- bluca-APJUtua8uzqonA0d6jMUrA@public.gmane.org
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

Re: [dracut] Loading of modules that don't have a uevent or pci device: ideas?

[Harald Hoyer]

On 12/21/2009 10:26 PM, Konrad Rzeszutek Wilk wrote:
> Hey Harald and initramfs mailing list,
>
> I am working on de-coupling a lot of Xen modules from the PV-OPS
> kernel (git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git)
> so that it is not neccessary to have them compiled in.
>
> I've gotten to the point that all of the drivers (fbfront, kbdfront,
> netfront, blkfront, pcifront) can be loaded on demand. Some of them
> can't be unloaded (still working on that).
>
> The next stage is to make the loading automatic, and detect if the kernel
> is running under Xen (PV) and if so load the neccesssary modules.
>
> To solve that, my thought was to:
>
> a) Write udev rules that would be act up if the kernel emitted such
> rules. But the kernel does not emit any uevents for this purpose and
> it does not emit any virtualization ones until the virtualization modules
> are loaded.  I could write up code that would emit this
> information and be generic enough that it would do so for anything
> that uses the paravirt strutures. So basically a SysFS interface for
> the paravirt interface.
>
> b) Or utilize xen-detect and load the appropiate modules if we are
> running in Xen PV land. The second is by far much simpler but I don't
> know if more appropiate. I am attaching an example patch to demonstrate
> what I had in mind. (Caveat: I didn't include the pre-requisite for
> xen-tools yet).
>
> c). Another way? Any ideas would be much appreciated.
>

pushed until the kernel can autoload those modules