[RFC] shipping kernels with default modules?

[Warner Losh]

On Jun 11, 2011, at 2:43 PM, David Schultz wrote:

> On Sat, Jun 11, 2011, mdf at freebsd.org wrote:
>> On Sat, Jun 11, 2011 at 10:18 AM, David Schultz <das at freebsd.org> wrote:
>>> On Sat, Jun 11, 2011, Adrian Chadd wrote:
>>>> Hi guys,
>>>> 
>>>> Has there been any further thought as of late about shipping kernels
>>>> with modules only by default, rather than monolithic kernels?
>>>> 
>>>> I tried this experiment a couple years ago and besides a little
>>>> trickery with ACPI module loading, it worked out fine.
>>>> 
>>>> Is there any reason we aren't doing this at the moment? Eg by having a
>>>> default loader modules list populated from the kernel config file?
>>> 
>>> I've been doing this for years, and it has come in quite handy.
>>> For instance, when my if_msk gets wedged, the only way to fix it
>>> short of rebooting seems to be reloading the driver.
>>> 
>>> One issue, however, is that the boot loader is horrendously slow
>>> at loading modules.  (Either that or my BIOS has a braindead int 13h
>>> handler.)  Most of these modules aren't actually needed until much
>>> later in the boot process, so a mechanism to load non-essential
>>> modules after the file systems are mounted might provide a good
>>> solution.
>> 
>> Indeed, at $WORK we're trying to get shutdown -> restart under 2
>> minutes.  Several seconds of this is moving things *into* the kernel
>> that need to be there (disk drivers), and everything else to a point
>> in init where modules can be loaded in parallel, using the faster disk
>> driver, rather than in serial with slow BIOS handlers.
> 
> Have you found that drivers can be reliably loaded in parallel
> these days?  I'm always waiting for timeouts on four card readers
> and two optical drives, so that would be a big win for me.  IIRC,
> nothing can happen in parallel during boot because the scheduler
> is initialized very late in the process.  I'm not a device driver
> person, but I imagine there might be other assumptions that might
> get in the way as well.

Loading isn't the problem.  The timeouts that you are waiting for are part of the probe/attach sequence.  And that's strictly serialized...

Warner