In need of some help understanding load-modules.sh and the boot proces

Question

umm i was bored a little whiel ago, then i rememberd recent posts about how slow arch boots,,
and also relating the an article in the wiki, about disabling load-modules.sh in variosu ways.
then i got thinking, why remove functionality for just 10 seconds? why not make it faster;;
i know, let's write it in C and see what we can get out of it.
anyway, a couple questions.
i looked in /lib/udev/load-modules.sh; where i encounter these lines;;
depmods="$(/sbin/modprobe -i --show-depends $1)"
depmods="$(echo $depmods \
| sed "s#^insmod /lib.*/\(.*\)\.ko.*#\1#g" \
| sed 's|-|_|g')"
i'm sure i must be missing something. but is $depmods really supposed to be return 1 element, i.e $1. ?
and where does /lib/initcpio/udev/load-modules.sh come into play.

Answer 1

@phrakture:
hmm, i wanna boot the system in dash now... *itch*itch* should i scratch it?
@klixon:
the script works perfectly as-is,
there was an update about an hour ago or something.
the line you refer to, was broken. i was just messing around with it
to see ho much faster i could make it.
i scratched it,
it booted ok,
except when it came boot start the gdm daemon at the end of the daemons array.
i couldn't test if it booted any faster as bootchartd had syntax errors, same as the gdm issue
===========================================================================================
update::
if [ -n "$BLACKLIST" ]; then
depmods="$(/sbin/modprobe -i -q --show-depends $1 | sed -e 's|-|_|g')"
if [ -z "$depmods" ]; then
/usr/bin/logger -p info "cannot find module $1"
#echo "MISSING[ $1 ]"
exit 1
fi
for blackmod in $BLACKLIST; do
if [[ $depmods == *"/$blackmod.ko"* ]]; then
/usr/bin/logger -p info "udev load-modules: $blackmod is blacklisted"
#echo "BLACKLISTED[ $blackmod ]"
exit 1
fi
done
fi
it appears that by doing the search the other way round, i.e
check if there is a blacklisted mod as dependency as opposed to a mod is blacklisted
doing so we can eliminate most of the sensitization
and chain the remaining san. to the modprobe,
long story short
the code above appears to be about 1.6 times faster than the current implementation
Last edited by kumico (2008-03-18 10:53:47)