Courses/Computer Science/CPSC 457.W2013/Lecture Notes/Startup

System Startup

In this session, we will examine how an operating system actually starts up and transitions from a simple sequential loading program to a concurrent system of processes.

Besides highlighting the relationship between system code and the hardware/architecture, it provides a good segue to concurrency.

Focus Question

How does an OS create the environment and conditions on the hardware necessary to support the concurrent execution of multiple processes?

Agenda

• Boot.
• OS startup slides
• OS startup code (see call chain list below)

Notes and References

• http://lxr.linux.no/#linux+v2.6.27.41/Documentation/x86/i386/boot.txt
• man dmesg (dmesg is the log of all startup activity)

The call chain involved here is interesting for several reasons:

• It shows you how deep some kernel call chains are (reflecting the design pattern of doing a little bit of work and deferring the next little bit of work to someone else)
• It demonstrates how closely the startup code is related to the underlying machine
• It is an exact reflection of going from sequential assembly code to a concurrent system by "manually" setting up kernel data structures, initializing subsystems, asking the scheduler to start, and creating a new kernel thread (via do_fork()) that eventually calls sys_execve() to load in the "first" user level process: /sbin/init.

Fascinating stuff.

• http://lxr.linux.no/#linux+v2.6.27.41/arch/x86/boot/header.S#L297 (real mode startup assembly code)
• http://lxr.linux.no/#linux+v2.6.27.41/arch/x86/boot/main.c (jumped to from startup assembly code)
• http://lxr.linux.no/#linux+v2.6.27.41/arch/x86/boot/pm.c (transfer to protected mode)
• http://lxr.linux.no/#linux+v2.6.27.41/arch/x86/boot/compressed/head_32.S#L35 (startup_32, version 1)
• http://lxr.linux.no/#linux+v2.6.27.41/arch/x86/kernel/head_32.S#L85 (startup_32, uncompressed version)
• http://lxr.linux.no/#linux+v2.6.27.41/arch/x86/kernel/head_32.S#L604 (startup_32 control flow eventually gets here, after executing idt setup); this location is a call to the x86-specific start_kernel routine:
• http://lxr.linux.no/#linux+v2.6.27.41/arch/x86/kernel/head32.c#L16 (which calls start_kernel() at line 40)
• http://lxr.linux.no/#linux+v2.6.27.41/init/main.c#L539, which at line 691 calls rest_init():
• http://lxr.linux.no/#linux+v2.6.27.41/init/main.c#L460. rest_init() then creates a kernel thread via a call to kernel_thread():
  • http://lxr.linux.no/#linux+v2.6.27.41/arch/x86/kernel/process_32.c#L233, which winds up asking do_fork():
  • http://lxr.linux.no/#linux+v2.6.27.41/kernel/fork.c#L1314 to do the work, which brings us back to the topic of process creation.
  • This call to kernel_thread is supplied an argument that points to the function kernel_init():
• http://lxr.linux.no/#linux+v2.6.27.41/init/main.c#L836. kernel_init() then finishes by calling init_post() at:
• http://lxr.linux.no/#linux+v2.6.27.41/init/main.c#L795, which attempts to invoke /sbin/init via run_init_process():
• http://lxr.linux.no/#linux+v2.6.27.41/init/main.c#L786, which asks kernel_execve():
  • http://lxr.linux.no/#linux+v2.6.27.41/arch/x86/kernel/sys_i386_32.c#L239 to create a new, in-kernel task, which calls sys_execve() from within the kernel:
  • http://lxr.linux.no/#linux+v2.6.27.41/arch/x86/kernel/process_32.c#L670, which brings us full circle to loading a process image.

Readings

• "It Can Be Done" (Multics anecdote; writing correct code with a pencil)
• MOS: 10.3.5: "Booting Linux"
• An Ode to Real Mode Setup Code