Noah, First of all, congratulations on the great work you are doing!
> In inetboot (also ufsboot and hsfsboot), when control is transferred to the > kernel, the NFS and network stack(tcp/ip, rarp, bootparamd) modules have not > yet been loaded. The kernel needs to callback the services (called boot > service in code base) of the inetboot bootstrap to read in those required > modules from root fs and link them, pretty complex. > > In multiboot, the boot_archive that includes those modules is mounted as > root fs via ramdisk. It is much simplier for the kernel to load and link > them. The different between x86 and sparc is supposed to be transient. Sun is working hard to make sparc boot ramdisk based as well. > The trick is the run time linking that reads in modules one by one. so what > is the benefit of it in kernel startup and why not just link those required > modules in build time (like Xen), which may posibbly save some booting > seconds? Because the boot path can't be predetermined, there are always driver modules you need to link in at run time. Unlike Linux, we don't ask sysadmin to recompile the kernel in order to boot from a new device. Once we move to ramdisk-based boot, the linking time will be fast. Shudong
