Introduction

In UNIX-like operating systems, once the kernel is alive and running, it starts another program, and most of the time, this is a daemon such as init that handles subsequent process spawning and completing the boot process. To achieve a bootstrap, init runs a vendor-specific script that, in turn, may run other scripts (depending on whether the init style in question is System V or BSD). Unfortunately, most of these driver scripts are fundamentally unchanged to reflect the needs and capabilities of newer computers.

The philosophy of mod-boot is that totally replacing an established and stable daemon is unnecessary for massively accelerating, standardizing, and enhancing the boot process.

Details

The general boot process can be outlined this way:

1. POST completes and control is passed to the bootloader
2. The bootloader initiates the kernel boot proceedure.
3. The kernel runs a program, generally init.
4. Init does some black magic, and runs a system configuration script to get everything ready
5. Init executes a script specified in /etc/inittab for the default runlevel (also specified in /etc/inittab)
6. System is ready to roll.

An overview of mod-boot is as so:

1. init runs mod-boot with a single command line argument that tells it what to do
2. mod-boot reads a cache file created by the install_initd program needed by the LSB, and uses that to create an array of script structs
3. Modification dates of the scripts for the requested command are used to check if the cache file should be regenerated
4. The scripts are executed asynchronously using threads in the orders determined by the cache file