Linux kernel architecture

Linux kernel architecture
Summary

Two reasons for Linux kernel success:

1. The architecture design supports a large number of volunteer developers to join the development process;
2. Each subsystem, especially those that need improvement, supports good scalability.

These two reasons allow Linux kernel to evolve continuously.

 

I. Linux kernel location in the entire computer system

Fig 1-Computer System Hierarchy

Layered structure principle:

the dependencies between subsystems are from the top down: layers pictured near the top depend on lower layers, but subsystems nearer the bottom do not depend on higher layers.

The dependency between subsystems can only be from top to bottom, that is, the subsystems at the top of the figure depend on the subsystems at the bottom, and vice versa.

 

Ii. Functions of the kernel

1. Virtualization (abstraction) abstracts computer hardware into a virtual machine for use by user processes. It does not need to know how hardware works when processes are running, you only need to call the virtual interface provided by Linux kernel.
2. Multi-task processing is actually the parallel use of computer hardware resources by multiple tasks. The core task is the use of resources by arbitration, making every process think that they are the illusion of exclusive system.

PS: process context switch is to replace the program status word, replace the content of the base address register of the page table, replace the task_struct instance pointed to by current, replace the PC --> and replace the file opened by the process. (The files of task_struct can be found) and replaced the execution space of the Process Memory (which can be found through the mem of task_struct );

 

Iii. Overall Linux kernel architecture

Overall Linux kernel architecture

The central system is the Process sched (SCHED): All other subsystems depend on the Process Scheduler, because other subsystems need to block and recover processes. When a process needs to wait for a hardware action to complete, the corresponding subsystem will block the process; when the hardware action is completed, the subsystem will restore the process: the blocking and recovery actions depend on the Process scheduler.

Each dependency arrow in has a reason:

• The process scheduler depends on the Memory manager (Memory manager). When a process is resumed for execution, the Memory manager must be used to allocate Memory for it to run.
• The IPC subsystem depends on the Memory Manager. The shared memory mechanism is a method for inter-process communication. Two processes run to transmit information using the same shared memory space.
• VFS depends on Network Interfaces: supports NFS Network file systems;
• VFS depends on Memory Manager: supports ramdisk Devices
• The Memory Manager depends on VFS. To support swapping, you can switch a non-running process out of the swap partition (swap) on the disk and suspend it.

 

4. A highly modular system facilitates division of labor and cooperation.

1. Only a few programmers need to work across multiple modules. This does happen only when the current system depends on another subsystem;
2. Hardware device drivers, file system modules, network device drivers, and network protocol modules) these four modules have the highest scalability.

 

V. Data Structure in the system

1. Task List)
   The process scheduler maintains a data structure task_struct for each process. All processes are managed using a linked list to form a task list. The process scheduler also maintains a current pointer pointing to the process currently occupying CPU.
2. Memory Map ing (Memory Map)
   The Memory Manager stores the ing of virtual addresses of each process to physical addresses. It also provides how to swap out specific pages or perform page missing processing. The information is stored in the data structure mm_struct. Each process has a mm_struct structure. In the task_struct structure of the process, a pointer mm points to the mm_struct structure of the secondary process.
   In mm_struct, there is a pointer pgd pointing to the page Directory table of the process (that is, the first address of the page Directory) --> when the process is scheduled, the pointer is replaced with a physical address, write control register (page base register under x86 architecture)
3. I-nodes
   VFS uses the inodes node to indicate the file image on the disk. inodes is used to record the physical properties of the file. Each process has a files_struct structure, which indicates the files opened by the process and has a file pointer in task_struct. Inodes can be used to share files. There are two ways to share files: (1) open the file through the same system and point to the same inodes node. This happens between parent and child processes; (2) open a file through different systems and direct it to the same inode node. For example, there is a hard link; or two irrelevant pointers open the same file.
4. Data Connection)
   The root of all the data structures in the kernel is in the list of tasks maintained by the Process scheduler. The data structure task_struct of each process in the system has a memory ing information pointing to it by the pointer mm; there is also a pointer files pointing to the file opened by the user (the user opens the file table ); there is also a pointer to the network socket opened by the process.

 

6. subsystem architecture

 

1. Process Scheduler Architecture

 

(1) Objectives

The process scheduler is the most important subsystem in Linux kernel. The system uses it to control the access to the CPU-not only the access to the CPU by the user process, but also the access to the CPU by other subsystems.

 

(2) Module

Process Scheduler

Scheduling policy module: determines which process gets access to the CPU. The scheduling policy should make all processes share the CPU as fairly as possible.

• Architecture-specific module designs a set of unified abstract interfaces to shield hardware details of specific system interface chips. This module interacts with the CPU to block and recover processes. These operations include obtaining the registers and status information that each process needs to save, and executing assembly code to complete blocking or recovery operations.
• The interaction between the architecture-independent module and the scheduling policy module determines the next execution process, and then calls the system structure-related code to resume the execution of the process. In addition, this module also calls the Memory Manager interface to ensure that the memory ing information of blocked processes is properly saved.
• The system call interface module allows user processes to access resources explicitly exposed to user processes by Linux Kernel. By defining a set of suitable basically unchanged interfaces (POSIX standard), you can decouple your applications from the Linux kernel so that your processes will not be affected by kernel changes.

 

(3) Data Representation

The scheduler maintains a data structure-task list. When elements are contained, the task_struct instance of each active process. This data structure not only contains information for blocking and resuming processes, it also contains additional count and status information. This data structure is publicly accessible throughout the kernel layer.

 

(4) Dependency, data flow, and control flow

As mentioned above, the scheduler needs to call the functions provided by the Memory Manager to select the appropriate physical address for the process to be resumed, therefore, the process scheduler subsystem depends on the memory management subsystem. When other kernel subsystems need to wait for the completion of hardware requests, they all rely on the process scheduling subsystem for process blocking and recovery. This dependency is reflected by function calls and access to the shared task list data structure. All kernel subsystems need to read or write the data structure of the currently running process, thus forming a two-way data flow throughout the system.

In addition to the data flow and control flow at the kernel layer, the OS service layer also provides interfaces for user processes to register timers. This forms the control flow of the scheduler to the user process. Generally, the use case of a sleep process is out of the normal control flow, because the user process cannot predict when the sleep process will be awakened. Finally, the scheduler interacts with the CPU to block and recover processes, which forms the data flow and control flow between them. The CPU is responsible for interrupting the currently running process, and allows the kernel to schedule other processes to run.

 

2. Memory Manager architecture

 

(1) Objectives

The memory management module controls how processes Access physical memory resources. The Hardware Memory Management System (MMU) is used to manage the ing between virtual memory of processes and physical memory of machines. Each process has its own virtual memory space, so the two processes may have the same virtual address, but they actually run in different physical memory areas. MMU provides memory protection so that the physical memory space of two processes does not interfere with each other. The memory management module also supports SWAp-swap out swap partitions from memory pages that are not currently used to the disk. This technology allows the virtual address space of the process to be larger than the physical memory size. The size of the virtual address space is determined by the machine font length.

 

(2) Module

Memory Management Subsystem

• The architecture-related module provides a virtual interface for accessing the physical memory;

• The architecture independent module is responsible for address ing and virtual memory switching for each process. When a page missing error occurs, the module determines which memory page should be swapped out of the memory. This is because this memory page has almost no change to the selection algorithm, therefore, there is no independent policy module.

• The system call interface provides strict access interfaces (malloc and free; mmap and ummap) for user processes ). This module allows the process to allocate and release memory and perform memory ing file operations.

 

(3) Data Representation

Memory Management stores the ing information between virtual memory and physical memory of each process. This ing information is stored in the mm_struct structure instance, and the pointer of this instance is stored in the task_struct of each process. In addition to storing ing information, data blocks should also store information about how the memory manager gets and stores pages. For example, the executable code can store the executable image as a backup, and the dynamic applied data must be backed up to the system page. (I don't understand this. Could you please help me ?)

Finally, the memory management module should also store access and technical information to ensure system security.

 

(4) Dependency, data flow, and control flow

The memory manager controls the physical memory. When the page fails (page fault), it receives a hardware notification (page disconnection) -- this means that there is a two-way data flow and control flow between the memory management module and the memory management hardware. Memory Management also relies on the file system to support swap and memory ing I/O-this requirement means that the memory manager needs to call the function interface (procedure CILS) provided to the file system ), store the memory page to the disk and retrieve the memory page from the disk. Because file system requests are very slow, before waiting for the memory page to be swapped in, the memory manager needs to sleep the process-this requirement allows the Memory Manager to call the interface of the Process scheduler. Since the memory ing of each process is stored in the data structure of the Process scheduler, there is also a two-way data flow and control flow between the memory manager and the process scheduler. A user process can create a new process address space and detect page missing errors. The control flow from the memory manager is required. Generally, there is no data flow from the user process to the memory manager, but the user process can be called through the select system to obtain some information from the memory manager.

 

3. Virtual File System Architecture

 

(1) Objectives

The Virtual File System provides unified access interfaces for data stored on hardware devices. Compatible with different file systems (ext2, ext4, ntf, etc ). Almost all hardware devices in a computer are represented as a universal Device Driver Interface. Logical file systems promote compatibility with other operating system standards and allow developers to implement file systems with different policies. The Virtual File System goes further, allowing the system administrator to mount any logical File System on any device. The Virtual File System encapsulates the details of physical devices and logical file systems, and allows user processes to access files using unified interfaces.

In addition to the traditional file system goals, VFS is also responsible for loading new executable files. This task is completed by the logical file system module, allowing Linux to support multiple executable files.

 

(2) Module

Virtual File System Module

• Device driver module)
• Device Independent Interface: provides the same view of all devices.
• Logical file system: For each supported file system
• The system independent interface provides interfaces unrelated to both hardware resources and the logical file system. This module provides all resources through block device nodes or character device nodes.
• The system call interface provides unified access control for file systems by user processes. The Virtual File System shields all special features of user processes.

 

(3) Data Representation

All files are represented by inode. Each inode records the location information of a file on the hardware device. In addition, inode also stores function pointers pointing to logical file system modules and device drivers. These pointers can perform specific read/write operations. Store function pointers in this form (that is, the idea of virtual functions in the object-oriented model, specific logical file systems and device drivers can register themselves with the kernel without the kernel dependency on specific module features.

 

(4) Dependency, data flow, and control flow

A special device driver is ramdisk, which opens up an area in the primary storage and uses it as a persistent storage device. This device driver uses the memory management module to complete the task, so there is a dependency between VFS and the memory management module (the dependency in the figure is reversed, it should be VFS dependent on the memory management module), data flow and control flow.

The logical file system supports network file systems. This file system accesses files from another machine just like accessing local files. To achieve this function, a logical file system completes its tasks through the network subsystem-This introduces a dependency between VFS on the network subsystem and the control flow and data flow between them.

As mentioned above, the memory manager uses VFS to implement memory switching and memory ing I/O. In addition, when VFS waits for the completion of the hardware request, VFS needs to use the process scheduler to block the process. When the request is complete, VFS needs to wake up the process through the process scheduler. Finally, the system calls an interface that allows a user process to call to access data. Unlike the previous subsystem, VFS does not provide a mechanism for user registration that is not explicitly called, so there is no control flow from VFS to user processes.

 

4. Network Interface Architecture

 

(1) Objectives

The network subsystem enables the Linux system to connect to other systems through the network. This subsystem supports many hardware devices and many network protocols. The network subsystem shields the hardware and protocol implementation details, it also abstracts simple and easy-to-use interfaces for user processes and other subsystems-user processes and other subsystems do not need to know the details of hardware devices and protocols.

 

(2) Module

Network protocol layer module diagram

• Network device drivers)
• The device independent interface module provides consistent access interfaces for all hardware devices, so that the high-level subsystem does not need to know the hardware details.
• The network protocol module implements each network transmission protocol, such as TCP, UDP, IP, HTTP, and ARP ~
• The protocol independent interface provides consistent Interfaces independent of specific protocols and hardware devices. This allows other kernel subsystems to access the network without relying on specific protocols or devices.
• The system call interface module specifies the network programming API that a user process can access.

 

(3) Data Representation

Each network object is represented as a socket ). The method associated with the socket and process is the same as that of the inode node. Two task_struct points to the same socket, which can be shared by multiple processes.

 

(4) data flow, control flow, and dependency

When the network subsystem needs to wait for the completion of the hardware request, it needs to use the process scheduling system to block and wake up the process-this forms the control flow and data flow between the network subsystem and the process scheduling subsystem. Moreover, the virtual file system implements the Network File System (NFS) through the network subsystem, which forms the data flow and control flow of the VFS and the network subsystem.

 

VII. Conclusion

1. the Linux kernel is a layer in the entire Linux system. The kernel consists of five major subsystems: Process scheduler module, memory management module, virtual file system, network interface module, and inter-process communication module. These modules interact with each other through function calls and shared data structures.

2. the Linux kernel architecture promotes his success. This architecture allows a large number of volunteer developers to cooperate with scoring engineers and make specific modules easy to expand.

• Scalability 1: the Linux architecture uses a data abstraction technology to make these subsystems Scalable-each specific hardware device driver is implemented as a separate module, this module supports unified interfaces provided by the kernel. In this way, individual developers can add new device drivers to the Linux kernel by performing the least interaction with other kernel developers.
• Scalability 2: the Linux kernel supports a variety of different architectures. In each subsystem, Code related to the architecture is separated to form a separate module. In this way, when some manufacturers launch their own chips, their kernel development team only needs to re-implement the machine-related code in the kernel, the kernel can be transplanted to a new chip for running.

 

References:

1. Http://oss.org.cn/ossdocs/linux/kernel/a1/index.html
2. Http://www.cs.cmu.edu/afs/cs/project/able/www/paper_abstracts/intro_softarch.html
3. Http://www.cs.cmu.edu/afs/cs/project/able/www/paper_abstracts/intro_softarch.html
4. Http://www.fceia.unr.edu.ar/ingsoft/monroe00.pdf

This article permanently updates the link address: