Re: rc.d script to load kernel modules

Al 12/06/11 10:56, En/na Jason Hellenthal ha escrit:
>
> 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.
>

  I wouldn't say that. There are cases where kldloading modules from
loader.conf take longer than kldloading them from rc.d scripts.

  For example, in my case, I'm booting from a zfs-only installation.
Kldloading a ten or twelve modules in loader.conf takes a long time
compared to a UFS-only installation. Moving them to a rc.d script would
allow me to save a lot of time during the boot process.

  I do agree that it is dangerous to move certain modules like umass
from loader.conf. For example, a NAS or pfsense installation would like
to mount a umass device as the root filesystem. So I think this case is
a little bit complicated. A brief messages explaining that umass needs
to be kldloaded from loader.conf in the case of a usb as the root
filesystem would be enough.

  So if we plan to have the possibility to do zfs-only installations in
a near future (I think pcbsd people would love this) I think it is not a
bad idea to move the kldloading of certain modules from loader.conf to
the rc infrastructure.

  Best regards,

  Gustau