Re: rc.d script to load kernel modules

On Sun, Jun 12, 2011 at 12:14:25PM +0200, Gustau Pérez wrote:
> 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.
> 

So technically here a ZFS only install is lacking the speed in which
modules are loaded. I would prefer to find out why and fix that before
we go about adding new functionality to rcNG.

This is not a "I am apposed to adding it" but rather a lets not just
side track what is actually happening.

Personally after giving this some more thought I would not mind seeing
the same syntax as in loader.conf brought to rc.conf. I think this would
lead to the least amount of confusion while giving the most amount of
control.

Example:
zfs_load="YES"
nullfs_load="YES"

- or - (for grouping)
load_nullfs="YES"
load_zfs="YES"

- or - 

kldload_nullfs="YES"
kldload_zfs="YES"

While I like to keep things grouped and lean toward that more I think
keeping the original syntax and just adding that to rc.conf capability
would be a good move.

>   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.
> 

-- 

"Unity can only be manifested by the Binary. Unity itself and the idea of Unity are already two." -- Buddha

 Regards, (jhell)
 Jason Hellenthal