rc.d script to load kernel modules
jhell at DataIX.net
Sun Jun 12 08:56:56 UTC 2011
On Sat, Jun 11, 2011 at 03:17:47PM -0700, Doug Barton wrote:
> Per discussion on -arch and the svn list about improving boot time and
> stripping down the kernel to just that-which-cannot-be-modularized I
> created the attached script to kldload modules that don't need to be in
> loader.conf. It cut quite a bit of time off my boot, so hopefully it
> will be useful to others as well.
> To use it just put everything that is being _load'ed in loader.conf into
> kld_list in rc.conf[.local]. For example, mine has:
> kld_list='umass coretemp ichwd linux nvidia if_wpi'
> If there is agreement that this is a good direction to go I'll be happy
> to commit this along with the relevant /etc/defaults/rc.conf and
> rc.conf.5 changes.
umass for one I could see how it would speed up your boot since you
would not have to probe for USB devices to possibly mount root from but
not a big show stopper for those who don't need that so this would come
in handy in that case but could also be handled by devd more elequently.
coretemp ichwd linux nvidia if_wpi: I can't really see how this would
speed up booting at all since the same initialization is going to be
done after root is mounted or before root is mounted. Whats the
difference here ?
Cutting modules out of the kernel in general does help speed up booting
but loading those same modules later in the boot process will just lead
you back to the same boot time. So all in all this would be just
subverting what loader.conf already does quite nicely... just loads.
Is there some other motivation besides boot times ? that is inspiring
the move from loader.conf to rc.onf[.local] ?
And then sticking to the semantics of the rest of the rc system not to
put a color on this but [following].
kldload_list="mod1 mod2 mod3 mod4 mod5"
Seems to make sense if it has to happen. *shrug*
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20110612/5bc27760/attachment.pgp
More information about the freebsd-current