Module load order needs to change

Bug #25787 reported by Ben Collins on 2005-11-15
6
Affects Status Importance Assigned to Milestone
usplash (Ubuntu)
Medium
Unassigned

Bug Description

With 2.6.15, the softcursor module needs to be loaded before fbcon, since fbcon
uses symbols from softcursor. Nothing deps on softcursor (in modules.deps), so
loading it first is the safe bet.

Also, with 2.6.15, the location of softcursor changed from:

/lib/modules/`uname -r`/kernel/drivers/video/softcursor.ko

to

/lib/modules/`uname -r`/kernel/drivers/video/console/softcursor.ko
                                             ^^^^^^^

Matt Zimmerman (mdz) wrote :

This really ought to just use modprobe.

Colin Watson (cjwatson) wrote :

IIRC when this was last discussed the consensus was that it should use modprobe
--show-depends at initramfs build time to construct the insmod lines, since
there may not be an up-to-date modules.dep in the initramfs (generating one is
expensive, and the initramfs may be assembled from multiple pieces at boot time
so it can't be pregenerated).

Matt Zimmerman (mdz) wrote :

(In reply to comment #2)
> IIRC when this was last discussed the consensus was that it should use modprobe
> --show-depends at initramfs build time to construct the insmod lines, since
> there may not be an up-to-date modules.dep in the initramfs (generating one is
> expensive, and the initramfs may be assembled from multiple pieces at boot time
> so it can't be pregenerated).

It seems perfectly reasonable to me for it to assume that modules.dep is
up-to-date enough for its purposes. If and when we start assembling initramfs
from pieces at boot time, we can address any issues which may arise, but today,
initramfs provides a 100% valid modules.dep generated when it is built, and
usplash can simply use modprobe in the usual way at boot time.

(In reply to comment #2)
> IIRC when this was last discussed the consensus was that it should use modprobe
> --show-depends at initramfs build time to construct the insmod lines, since
> there may not be an up-to-date modules.dep in the initramfs (generating one is
> expensive, and the initramfs may be assembled from multiple pieces at boot time
> so it can't be pregenerated).
>
There's definitely a guarantee, because the initramfs runs depmod! It's
actually not expensive, it's all on a tmpfs and the only overhead is I/O. It
takes a sufficiently small amount of time that time thinks it takes 0.00s

Matthew Garrett (mjg59) wrote :

Fixed in 0.1-23. Scott, initramfs doesn't seem to run depmod early enough - so,
for now, usplash is calling it as well. We may want to look into changing that.

Yeah, I think the reason it didn't was that load_modules has other side effects
(probing the bus, etc.) Now we've moved all of the udev code into a
init-premount script, there's no reason we can't move depmod further up...
*there*, ok, depmod loads before init-top now <g>

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.