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

> Is there a practical way to segregate part I from part II, that is to
> compile the "hardware bootstrapping", some drivers, hardware
> configuration in order to create a primitive kernel used as a bootloader
> (meaning the ability to use NetBSD sources to compile code to put in
> network cards EPROM, and the ability to achieve more than is actually
> done with other bootloaders)?

  How big is the boot ROM?  For i386 you might be able to squeeze
something that does what you want into 1MB or so (possibly under 500k
compressed) with a little work (assuming only one network card and two or
three file systems), but I don't think it would be too easy to get much
lower than that.  This would assume a minimal interface.  A kernel based
on GENERIC_TINY with the isa, pcmcia, and pci network cards listed in that
file (which is not all the supported cards and includes no wireless
drivers which are relatively large), vga, com, FFS, EXT2FS, MFS, NFS,
CD9660, and MSDOSFS (but almost no other drivers) is about 1.75MB (.75MB
compressed).  By comparison, a kernel with only a isa bus and no other
drivers at all is 806k (398k compressed).  The full GENERIC kernel is 7MB
(3.3MB compressed).

  I have not investigated in detail what all the non-driver code is used
for, but uvm and vfs are two big sections.  I don't know how much they can
be reduced, but most likely not too much.  The kernel-userland interface
does not take up that much of the kernel.  You might be able to save 75k
by removing it, but I think that is about it.

> 1) Ability to load/unload drivers -> going autoconf is partly already
> that ; but perhaps the network stuff (BOOTP/DHCP
> discover (for network cards EPROM) could be at this stage, meaning too
> the ability to retrieve additionnal drivers via UDP/IP)

  If you didn't catch it before, see the "A potential step toward
modularisation" thread last month on this list for some of the LKM issues.
I am not a fan of LKMs, but some of the options for device detection could
also make it possible to automatically detect hardware for static kernel
configuration without including all possible drivers.  I would prefer
separate probe functions to do this which could be statically linked into
the kernel or separately loaded and unloaded in bulk (per bus).  I don't
know what the current issues are with NetBSD LKMs.

> 4) The users interact with the primitive kernel via the kernel shell
> (autoconf prompt is something like that). And the "programs" are not
> external ones but in kernel ones (this simplifies the ABI).

  This would work for a basic interface, but of you assume network
availability anyway you might want to put this in userland on NFS (or just
in MFS in the kernel if you have the space).  Crunched simple userland
code doesn't take up that much space, and there is a lot of code that you
might potentially want to load a system (unfortunately most of it not so
simple).  Use of userland would make it easier to use much more code if
you need it with less changes.

Matthew Orgass
darkstar@city-net.com