Operating systems can boot in one of two ways. On some architectures ( e.g., the HP 300), booting the machine causes the ROM to perform some diagnostics, read the first block of the disk into memory, and execute it. This first block usually reads the next eight blocks, which comprise the stand-alone kernel, and executes them. The stand-alone kernel can do very little except read a file from the main filesystem and possibly boot from a network connection. The stand-alone kernel will look through the directory structure of a particular disk partition (the boot partition) for a file of a certain predefined name, such as unix, vmunix, or netbsd, load it into memory, clear the bss, and execute it. On other architectures ( e.g., the Macintosh), the kernel is loaded directly by an application (the booter) running in the native operating system ( e.g., MacOS). In this case, the stand-alone kernel is not used and its function is moved into the booter (see Section 2.4).
In either case, the stand-alone kernel is a great place to test device drivers and other experimental code without interference from interrupts, memory mapping, or the rest of the kernel. During the Macintosh port, we wrote and tested the display, serial port, keyboard, clock, and harddisk drivers before linking with any kernel code. We also tested some MMU mappings and interrupt behaviors. Another advantage is that the stand-alone kernel, being much smaller than the UNIX kernel, compiles faster, which results in faster development cycles.