Linux Kernel Internals module so there are no problems But what if both a and b are statically linked into the kernel?The order they are invoked depends on the relative entry point offsets in the"initcall.init"ELF section of the kernel image.Rogier Wolff proposed to introduce the hierarchical "priority"infrastructure whereby modules could let the linker know in what(relative)order they should be linked but so far there are no patches available that implement this in a sufficiently elegant manner to be acceptable into the kernel.Therefore-make sure your link order is correct,if,in the example above,A and B work fine when compiled statically once they will work always provided they are listed sequentially in the same Makefile.If they don't work change the order their object files are listed. Another thing worthy of note is Linux's ability to execute"alterative init program"by means of passing init="boot commandline.This is useful for recovering from accidentally overwritten"/sbin/init"or debugging the initialisation(re)scripts and /etc/inittab by hand,executing them one at a time. 1.7 SMP Bootup on x86 On SMP,the BPgoes through the normal sequence of bootsector,setup etc until it reaches the start_kemel( and then on to smp_init()a d calls mpboot.c:smp_boot_cpus(). smp_boot_cpus( goes in a op an on it.What do boo an e t get cp ons deepu( trampo ne.S The boot CPU cre ates a copy e code for each CPU in the low The AP code v the BP t writes ber that tramp oline ust be in ed by The trampoline code simply sets %bx register to 1,enters protected mode and jumps to startup 32 which is the main entry to arch/i386/kernel/head S. Now.the ap starts executing head s and discovering that it is not a bp.it skips the code that clears BSs and then enters initialise secondary()which just enters the idle task for this CPU-recall that init tasks[cpu]was already initialised by BPexecuting do boot cpu(cpu). Note,that init task can be shared but each idle thread must have its own TSS so init tss[NR CPUS]is an arrav 1.8 Freeing initialisation data and code When the operating system initialises itself most of the code and data structures are never needed again.Most operating systems(BSD,FreeBSD etc.)cannot dispose of this unneeded information thus wasting the precious physical kernel memory.The excuse they use(see McKusick's 4.4BSD book)is that"the relevant code is spread around various subsystems and so it is not feasible to free it".Linux,of course,cannot use such excuses because under Linux "if something is possible in principle,then it is already implemented or somebody is working on it" 1.7 SMP Bootup on x86 9module so there are no problems. But what if both A and B are statically linked into the kernel? The order they are invoked depends on the relative entry point offsets in the ".initcall.init" ELF section of the kernel image. Rogier Wolff proposed to introduce the hierarchical "priority" infrastructure whereby modules could let the linker know in what (relative) order they should be linked but so far there are no patches available that implement this in a sufficiently elegant manner to be acceptable into the kernel. Therefore − make sure your link order is correct, if, in the example above, A and B work fine when compiled statically once they will work always provided they are listed sequentially in the same Makefile. If they don't work change the order their object files are listed. Another thing worthy of note is Linux's ability to execute "alternative init program" by means of passing "init=" boot commandline. This is useful for recovering from accidentally overwritten "/sbin/init" or debugging the initialisation (rc) scripts and /etc/inittab by hand, executing them one at a time. 1.7 SMP Bootup on x86 On SMP, the BP goes through the normal sequence of bootsector, setup etc until it reaches the start_kernel() and then on to smp_init() and especially src/i386/kernel/smpboot.c:smp_boot_cpus(). The smp_boot_cpus() goes in a loop for each apicid (until NR_CPUS) and calls do_boot_cpu() on it. What do_boot_cpu() does is create (i.e. fork_by_hand) an idle task for the target cpu and writes in well−known locations defined by the Intel MP spec (0x467/0x469) the eip of trampoline code found in trampoline.S. Then it generates STARTUP IPI to the target cpu which makes this AP execute the code in trampoline.S. The boot CPU creates a copy of trampoline code for each CPU in the low memory. The AP code writes a magic number in its own code which is verified by the BP to make sure that AP is executing the trampoline code. The requirement that trampoline code must be in low memory is enforced by the Intel MP specification. The trampoline code simply sets %bx register to 1, enters protected mode and jumps to startup_32 which is the main entry to arch/i386/kernel/head.S. Now, the AP starts executing head.S and discovering that it is not a BP, it skips the code that clears BSS and then enters initialise_secondary() which just enters the idle task for this CPU − recall that init_tasks[cpu] was already initialised by BP executing do_boot_cpu(cpu). Note, that init_task can be shared but each idle thread must have its own TSS so init_tss[NR_CPUS] is an array. 1.8 Freeing initialisation data and code When the operating system initialises itself most of the code and data structures are never needed again. Most operating systems (BSD, FreeBSD etc.) cannot dispose of this unneeded information thus wasting the precious physical kernel memory. The excuse they use (see McKusick's 4.4BSD book) is that "the relevant code is spread around various subsystems and so it is not feasible to free it". Linux, of course, cannot use such excuses because under Linux "if something is possible in principle, then it is already implemented or somebody is working on it". Linux Kernel Internals 1.7 SMP Bootup on x86 9