Booting process of Linux: Difference between revisions

Content deleted Content added
Toughpigs please do not un-bold the texts
Toughpigs please do not un-bold the texts
Line 28:
 
== Kernel ==
The kernel stage occurs after the bootloader stage. The [[Linux kernel]] handles all operating system processes, such as [[memory management]], task [[scheduling (computing)|scheduling]], [[I/O]], [[interprocess communication]], and overall system control. This is loaded in two stages – in the first stage, the kernel (as a compressed image file) is '''loaded into memory''' and '''decompressed''', and a few fundamental functions are set up such as basic memory management, minimal amount of hardware setup.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} It's worth noting that kernel image is '''self-decompressed''', which is a part of the kernel image's '''routine'''.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} For some platforms (like ARM 64-bit), kernel decompression has to be performed by the bootloader instead, like U-Boot.{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Bootloader"|p=20}}
 
For details of those steps, take an example with [[i386]] microprocessor. When its bzImage is invoked, function <code>start()</code> (of <code>./arch/i386/boot/head.S</code>) is called to do some basic hardware setup then calls <code>startup_32()</code> (located in <code>./arch/i386/boot/compressed/head.S</code>).{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} <code>startup_32()</code>will do basic setup to environment (stack, etc.), clears the [[.bss|Block Started by Symbol]] (BSS) then invokes <code>decompress_kernel()</code> (located in <code>./arch/i386/boot/compressed/misc.c</code>) to decompressed the kernel.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} Kernel startup is then executed via a different <code>startup_32()</code> function located in <code>./arch/i386/kernel/head.S</code>.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} The startup function <code>startup_32()</code> for the kernel (also called the swapper or process 0) establishes [[memory management]] (paging tables and memory paging), detects the type of [[Central processing unit|CPU]] and any additional functionality such as [[floating point]] capabilities, and then switches to non-architecture specific Linux kernel functionality via a call to <code>start_kernel()</code> located in <code>./init/main.c</code>.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}}
 
{{Anchor|Early user space}}<code>start_kernel()</code>executes a wide range of initialization functions. It sets up [[interrupt handling]] ([[Interrupt request|IRQ]]s), further configures memory, mounts the [[initrd|initial RAM disk]] ("'''initrd'''") that was loaded previously as the temporary root file system during the bootloader stage.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} The initrd, which acts as a temporary root filesystem in RAM, allows the kernel to be fully booted and driver modules to be loaded directly from memory, without reliance upon other devices (e.g. a hard disk).{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} initrd contains the necessary modules needed to interface with peripherals,{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} e.g SATA driver, and support a large number of possible hardware configurations.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} This split of some drivers statically compiled into the kernel and other drivers loaded from initrd allows for a smaller kernel.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} [[initramfs]], also known as '''early user space''', has been available since version 2.5.46 of the Linux kernel,<ref>{{cite web |title=Initramfs arrives |url=https://lwn.net/Articles/14776/ |access-date=14 November 2011}}</ref> with the intent to replace as many functions as possible that previously the kernel would have performed during the startup process. Typical uses of early user space are to detect what [[device driver]]s are needed to load the main user space file system and load them from a [[temporary filesystem]]. Many distributions use [[dracut (software)|dracut]] to generate and maintain the initramfs image.
 
The root file system is later switched via a call to <code>pivot_root()</code> which unmounts the temporary root file system and replaces it with the use of the real one, once the latter is accessible.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} The memory used by the temporary root file system is then reclaimed.{{Clarify|date=March 2010}}