Linux Kernel Architecture

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:

1. 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.


2. 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


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.