Re: CVS commit: src/sys/arch/i386/conf

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

On Sun, Feb 13, 2011 at 04:29:25PM +0100, Jean-Yves Migeon wrote:
> On 13.02.2011 14:42, David Laight wrote:
> > On Sun, Feb 13, 2011 at 04:37:21AM +0000, Jean-Yves Migeon wrote:
> >> Module Name:       src Committed By:       jym Date:               Sun Feb 
> >> 13 04:37:21 UTC 
> >> 2011
> >> 
> >> Modified Files: src/sys/arch/i386/conf: GENERIC
> >> 
> >> Log Message: Compile FFS and NFS statically (e.g. not modular) for 
> >> GENERIC. These file-systems can be critical for mountroot; as 
> >> kernel cannot have access to module(7)s without having / mounted 
> >> first... yes, you see the point.
> > 
> > Does this cause grief with existing installations where the 
> > bootloader also loads these as modules?
> 
> No; if it does, it should not: the bootloader is free to load whatever
> modules it wants to, and this happens also when the user specifies it to
> load certain modules manually. It could print errors messages (although,
> in my tests, it did not), but should not hamper boot in any way.
> 
> IMHO, for x86, the kernel cannot assume that the bootloader loaded
> certain modules, nor can the bootloader expect that kernel XYZ is in a
> specific configuration. They should be agnostic from one another.

I think that TRT here is that kernel tells bootloader what to load.
This should be possible by allocating a static buffer shared by
bootloader/kernel, and kernel does reboot (== calling bootloader).

        bootloader
          load modules in the boot module list (initially nothing)
        kernel
          while (configure devices)
            if (module A not found)
              append A to the boot module list (static buffer)
              reboot
          mountroot
          :

The reason why this reboots the system repeatedly is that the kernel
has no knowledge of the exact hardware/mount configuration.  In other
words, the boot is non-deterministic.

The opposite case is static kernel configuration, typically embedded
platforms where hardware configuration is static.  In such a case,
you can configure kernel exactly for the specification.  The kernel
always boots in the same manner.  I.e. it is deterministic.

> Besides, that would be problematic if it were not the case: given that
> boot(8) can auto-load ffs or nfs kmods, the bootloader would be bound
> with modular kernels.
> 
> For order of preference, see module(7):
> 
>     The loader will look first for a built-in module with the specified
>     name that has not been disabled (see module_unload() below). If a
>     built-in module with that name is not found, the list of modules
>     prepared by the boot loader is searched.  If the named module is
>     still not found, an attempt is made to locate the module within the
>     file system.
> 
> -- 
> Jean-Yves Migeon
> jeanyves.migeon%free.fr@localhost

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635