Mauerer app04.tex V1 - 09/04/2008 6:12pm Page 1234
Appendix D: System Startup
/*
* Tell the world that we’re going to be the grim
* reaper of innocent orphaned children.
*/
init_pid_ns.child_reaper = current;
...
}
Register as child reaper
SMP initialization
Execute userspace initialization program
init
do_basic_setup
prepare_namespace
init_post
free_initmem
Figure D-3: Code flow diagram forinit.
Up to now, the kernel has used just one of the several CPUs on multiprocessor systems, so it’s time to
activate the others. This is done in the following three steps:
- smp_prepare_cpusensures that the remaining CPUs are activated by executing their
architecture-specific boot sequences. However, the CPUs are not yet linked into the kernel
scheduling mechanism and are therefore still not available for use. - do_pre_smp_initcallsis — despite its name — a mix of symmetric multiprocessing and
uniprocessor initialization routines. On SMP systems, its primary task is to initialize the
migration queue used to move processes between CPUs as discussed in Chapter 2. It also
starts the softIRQ daemons.^3 - smp_initenables the remaining CPUs in the kernel so that they are available for use.
Driver Setup
The nextinitstep is to start general initialization of drivers and subsystems using thedo_basic_setup
function whose code flow diagram is shown in Figure D-4.
Some of the functions are quite extensive but not very interesting. They simply initialize further kernel
data structures already discussed in the chapters on the specific subsystems.driver_initsets up the data
structures of the general driver model, andinit_irq_procregisters entries with information about IRQs
(^3) To be precise, the kernel invokes a callback function that starts the daemons when a CPU is activated by the kernel. Suffice it to say
that ultimately an instance of the daemon is started for each CPU.