Linux Kernel reading Summary

Next, let's take a look at the CFS learning summary. Next, let's take a look at some of the main modules of the Linux kernel that I saw a long time ago. This summary summarizes my memories of a specific module, not the source code, the main purpose is to strengthen your memory, and extract something to share with you (sometimes the code is too much to read, but there is no overall concept for a module ). I. Linux Startup Process Analysis

The Linux Startup Process can be divided into four phases: system power-on, bios, boot program, and Linux kernel.

(1) system power-on stage

For the X86 architecture, after the CPU is powered on, the EIP = 0 xFFFF fff0, And the CPU executes the EIP pointing command. This is usually a jump command, that is, the entry to the BIOS.

(2) BIOS stage

BiOS provides two main functions: power-on self-check, namely post (power on self test) and kernel boot program loading. Here we refer to MBR (Master Boot Record 512 bytes ), the post process mainly performs system hardware detection, such as memory detection and system bus detection.

(3) Pilot Program stage

The kernel boot program mentioned here consists of the Master Boot Program in MBR and the secondary boot program in the active partition. The primary boot program in MBR contains a 446-byte program and a 64-byte disk partition table. The primary boot program scans the disk partition table to find the active disk partition, load the secondary boot program in the active partition to the memory for execution. The secondary boot program is responsible for loading the kernel.

(4) Linux kernel stage

After the kernel is loaded into the memory, we first prepare for the kernel running. The main steps include:

• Set the C program running Stack
• Clear BSS segments
• Set the Interrupt Descriptor Table (IDT)
• Set Global Descriptor Table (gdt)
• Set the PE bit of Cr0 to enable the protection mode (after the protection mode is enabled, a long jump command must be followed to clear the command prefetch queue and reset the % CS segment register)
• Call the kernel decompression function-decompress_kernel () and jump to the kernel extraction portal.
• Set the PostgreSQL position of Cr0 and enable paging.

The basic idea is to find a secure memory zone in the memory, usually at the end of the kernel data segment or heap, in this memory segment, a memory segment starting with the physical address 0 is mapped to the addresses starting with 0xc000 0000 and 0x0000 in the virtual address space.

• Jump to start_kernel

Ii. Execution Process of Linux system calls

The execution process of a Linux system call can be described as follows:

(1) The application calls the functions in the C library.

(2) The implementation of the C-database function is to trigger the int 0x80 system call interruption. The system call number is in % eax.

(3) the operating system queries the interrupt vector table with the interrupt vector number 0x80 and executes the corresponding interrupt processing function.

(4) The interrupt processing function takes the system call Number % eax to query the system call table and executes the corresponding system call.

(5) return to the application after the execution of the system call is completed

Iii. Linux interrupt classification and interrupt handling process

Interrupt initialization includes initialization of the interrupt vector table, initialization of the interrupt array, and registration of the interrupt processing function.

Operations performed by hardware during interrupt generation and handling:

The device sends an interrupt signal to the interrupt controller through the interrupt request line (IRQ). After the interrupt controller receives the interrupt signal, on the one hand, the interrupt signal is converted to the interrupt signal through the decoding circuit, stored in the specified Io ports. On the other hand, the interrupt signal is sent to the CPU through the int line directly connected to the intr pin of the CPU;

After the CPU receives the interrupt signal, wait until the current command is executed. Before executing the next command, check whether the interrupt is in pending state. If yes, send a response signal to the interrupt controller through INTA, retrieve the interrupt number through data line, read the IDT table, and obtain the I entry in the IDT table corresponding to the interrupt number, then, select a child based on the segment specified in the IDT [I] Descriptor and search in the gdt table to obtain the base address of the interrupt handler, then, use the offset address of the interrupt handler specified in the base address + IDT [I] to obtain the address of the interrupt handler. Of course, there will also be some security checks when reading the IDT and gdt tables.

The CPU determines whether there are any changes in the privileged level (the user State falls into the kernel state). If yes, obtain the base address of the TSS segment through the tr register and read the SS and esp of the kernel state Stack from it, in this case, the user-state stack is switched to the kernel-state stack, and then the user-state SS and ESP are saved in the kernel stack. If the interrupt type is fault ), then, the value of CS and EIP is changed to the address of the instruction that causes the interruption, so that the instruction can be re-executed after the interruption processing is complete. Then, save the values of eflags, Cs, and EIP in the kernel stack. If there is a hardware error code, save it to the stack, and finally save Cs: the EIP value is assigned the offset of the base address of the interrupt handler + IDT [I.

The stack from the user State to the interrupt and from the kernel state to the interrupt is as follows.

IDT table initialization: Through set_intr_gate () and trap_init (), the latter is used to initialize 20 exceptions and a system call-related interrupt 0x80.

In init_irq (), call set_intr_gate (vector, interrupt [I]) cyclically to initialize the IDT table items corresponding to the vector. Here, the interrupt [256] array, the following code defines all interrupt processing functions as a unified entry: common_interrupt.

 

Architecture-independent interrupt handling process: do_irq ().

Irq_desc data contains 224 irq_desc_t descriptors. Each interrupt number corresponds to one descriptor. The action linked list in this descriptor points to the data structure of irqaction, representing the corresponding processing function of the interrupt, all the processing functions that share the same interrupt vector are mounted on this linked list. By traversing this linked list, you can check whether it is a device-registered processing function (dev_id ).

 

Softirq is statically allocated by the kernel and determined during compilation. The number of softirq instances is limited. Currently, the kernel supports 8/9 instances with priority, mainly related to timers, packet sending and receiving, and block devices, scheduling and tasklet. Check for executable soft interruptions at specific points:

(1) When local_bh_enable reactivate the Soft Interrupt

(2) After do_irq completes the interrupt handling process

(3) When ksoftirqd is awakened

Tasklet is the first choice for implementing deletable functions in the I/O driver. It is built on Soft Interrupt hi_softirq and tasklet_softirq. The difference between the two is that the priority is different, the two tasklets are managed by the corresponding arrays tasklet_vec and tasklet_hi_vec. Each item of the array corresponds to a CPU, that is, tasklet is bound to the CPU.

The workqueue consists of a work queue and a worker thread. The worker thread regularly scans the work queue for tasks that can be processed. The Soft Interrupt and tasklet run in the interrupt context, so they cannot sleep, workquue runs in the process context and can be sleep.