On 2004-03-08 tlaronde@polynum.com wrote:

> At first glance, it could seem that boostrap + stage 1 + machine
> dependent operations is what I'm after. But it's not so simple, since
> the machine-dependent initialization phase does things that are clearly
> "too much" for a bootloader [parts of the cpu_startup()], mainly the
> initialization of the system data structures.

  Why is it "too much" for the bootloader?  If it isn't a matter of space,
I don't see what the problem is with using the kernel as is (with a
minimal kernel config).  Boot time could be a concen, but this may be
fixable to your satisfaction with minimal changes that might also be
helpful in other situations.  I am not saying that there is nothing you
can do to improve the use of the kernel as a boot loader, but I think it
should be looked at from the perspective of optimizing what needs fixing.
Unless I missed something, I haven't seen you give particular requirements
that cannot be met without fundamental reductions to the kernel, only a
few additonal features that are not currently available (primarily, the
ability to load a new kernel on more ports).

> 	=> For i386, reusing the code means the bootloader will escape real
> 	mode rapidly, meaning that it will be unable to use the firmware
> 	(BIOS) if the virtual mode is not unabled. That's a pain by itself.
> 	And that's i386 too...

  See options(4) under VM86.

> In the case I'm looking for the "necessary actions" will mean trying to
> add/load the correct driver if it is not present and, at a minimum,
> print the identifier of the hardware in order to be able to compile a
> matching kernel.

  This would be nice to have, IMO.

> Alternatively, since as written (p498, same section) "Devices that are
> present but not recognized remain unavailable until the system is
> rebooted",

  I think this might be one of the wrinkles in NetBSD LKMs, but I don't
know for sure.  A lot has changed since that book was written.  I don't
think it would be too hard to change, if it hasn't already.

> add (the file is present in FreeBSD if I'm not mistaken) the possibility
> by the bootloader to write an autoconf file (hence, there will be static
> configuration, and the dynamic autoconfiguration will be the in kernel
> one + the mask provided by the autoconf file (enable/disable) --- this
> is already what is made but by hand when entering autoconf (boot -c)).

  I don't know how FreeBSD does this, but the obvious problem with this
that I see is that the file can't be accessed until the devices to get to
it are configured (unless the BIOS/firmware is used).  If the bootloader
is to be doing the config changes then it could be passed as bootinfo.
In general, I think it would be best if the file it is kept in is the
kernel itself.  I don't know how difficult it would be now to create a
utility that modifies the kernel, although I think the changes made to
allow userconf are the same ones that would make this possible so it may
be quite easy.

> I think that if the kernel is stripped done to the strict minimum of
> drivers, then one can use the full power of NetBSD in the minimal
> place, that's why I think, I may be wrong, that the bootloader ability
> must be spartan.

  I don't understand what you are saying.

> For NFS, since it involves bigger programs, is there the ability to
> change the rootfs at runtime? I mean, if the kernel is loaded with a
> minimal MFS which has NFS userland programs, is it possible to load the
> NFSclient to access the ressources and mount the NFS accessed fs as the
> root fs overriding the memory image?

  It is possible, although I don't know if the old root gets completely
replaced or the new root is mounted on top (I once accedently mounted my
msdos partition at root and had to reboot via the debugger).  It doesn't
matter in this case since kernel memory disks are not freeable.  In many
cases it is possible to mount NFS as root directly with a custom kernel
config specifying configuratiom parameters.  I don't know what all of the
limitations of this are.

Matthew Orgass
darkstar@city-net.com