Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to analyze the Linux kernel architecture. The content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Overview

In general, the Linux operating system, as shown in the following figure, consists of four major subsystems:

User application layer: the set of applications used on a particular Linux system varies, depending on the purpose of the computer system, but typical examples include word processing applications and Web browsers, and embedded Linux tends to do a lot of tailoring to cut out unwanted applications.

Oamp S service layer: Oamp S service is generally considered to be part of the operating system (window system, command shell, etc.); in addition, the subsystem also contains kernel programming interfaces (compiler tools and libraries d)

Linux kernel layer: this is the main subsystem of this article, and the kernel abstracts and regulates access to hardware resources, including CPU.

Hardware control layer: this subsystem consists of all possible physical devices in the Linux installation; for example, CPU, memory hardware, hard disk, and network hardware are all members of the subsystem

two。 Kernel architecture

2.1 the role of the kernel

The Linux kernel provides a virtual machine interface for user processes. Process programming does not need to know what physical hardware is installed on the computer, and the Linux kernel abstracts all hardware into a consistent virtual interface.

In addition, Linux supports multitasking in a way that is transparent to user processes: each process can work as if it were the only process on the computer, and is dedicated to consuming main memory and other hardware resources. The kernel actually runs multiple processes at the same time and is responsible for mediating access to hardware resources so that each process has fair access while maintaining inter-process security.

2.2 structure of the kernel

The kernel consists of the following five major components:

The process Scheduler (SCHED) is responsible for controlling process access to CPU. The scheduler implements a scheduling policy to ensure that the process has fair access to the CPU and that the kernel performs the necessary hardware operations on time.

The memory manager (MM) allows multiple processes to safely share the machine's main memory system. In addition, the memory manager supports virtual memory, which allows Linux to support processes that use more memory than is available to the system. Use the file system to swap unused memory out to persistent storage and then swap it back when needed.

Virtual File system (VFS) abstracts the details of various hardware devices by providing a common file interface for all devices. In addition, VFS supports several file system formats compatible with other operating systems.

The Network Interface (NET) provides access to several network standards and various network hardware.

The interprocess communication (IPC) subsystem implements multiple mechanisms for interprocess communication on a single Linux system.

From the perspective of dependence:

The process scheduler subsystem uses the memory manager to adjust the hardware memory mapping for restoring specific processes of a particular process.

The interprocess communication subsystem relies on the memory manager to support the shared memory communication mechanism. This mechanism allows two processes to access areas of public memory in addition to their usual private memory.

The virtual file system uses a network interface to support the network file system (NFS) and also uses a memory manager to provide ramdisk devices.

The memory manager uses a virtual file system to support swapping; this is the only reason why the memory manager depends on the process scheduler. When a process accesses currently swapped memory, the memory manager makes a request to the file system to obtain memory from persistent storage, and suspends the process.

2.3 important data structures of the kernel

Task linked list (Task List): the process scheduler maintains a data block for each active process. These blocks are stored in a linked list called a task list. The process scheduler always maintains a current pointer indicating the currently active process.

Memory mapping (memry map): the memory manager stores the mapping of virtual addresses to physical addresses on a per-process basis, as well as additional information about how to get and replace specific pages. This information is stored in the memory-mapped data structure, which is stored in the task list of the process scheduler.

Index node (I-node): the virtual file system uses an index node (index node) to represent files on the logical file system. The Inode data structure stores the mapping of file block numbers to physical device addresses. If two processes open the same file, you can share the I node data structure among multiple processes. Sharing is accomplished by two task blocks pointing to the same I node.

Data connection (Data Connection) all data structures are rooted in the task list of the process scheduler. Each process on the system has a data structure that contains a pointer to its memory mapping information and a pointer to the I node that represents all open files. Finally, the task data structure also contains pointers to the data structure that represents all open network connections associated with each task.

3. Analysis of the architecture of each subsystem

3.1 process Scheduler Architecture

The process scheduler is the most important subsystem in the Linux kernel. The purpose is to control access to the computer CPU. This includes not only the access of user processes, but also the access of other kernel subsystems.

As can be seen from the above figure, the process scheduler can be divided into four modules:

The scheduling policy module is responsible for determining which process can access the CPU;. The policy is designed to enable the process to access the CPU fairly.

Architecture-related modules architecture-specific module designs have a common interface that abstracts the details of any particular computer architecture. These modules are responsible for communicating with CPU to suspend and resume processes. These operations involve knowing which registers and state information each process needs to retain and executing assembly code to perform suspend or resume operations.

The architecture-independent module communicates with the policy module to determine which process will be executed next, and then calls the architecture-specific module to restore the appropriate process. In addition, this module calls the memory manager to ensure that the memory hardware is restored correctly for the recovery process

The system call interface module allows user processes to access only those resources that are explicitly exported by the kernel. This limits the dependency of the user process on the kernel to a well-defined interface, which rarely changes although the implementation of other kernel modules has changed

The process scheduler maintains a data structure, the task list, with one entry for each active process. This data structure contains enough information to pause and resume the process, but also contains additional billing and status information. The data structure can be used publicly throughout the kernel layer.

As mentioned earlier, the process scheduler will call the memory manager subsystem. Therefore, the process scheduler subsystem depends on the memory manager subsystem. In addition, all other kernel subsystems rely on the process scheduler to suspend and resume processes while waiting for the hardware request to complete. These dependencies are represented by function calls and access to shared task list data structures. All kernel subsystems read and write data structures that represent the current task, resulting in two-way data flow throughout the system.

In addition to the data and control flows in the kernel layer, the O / S service layer provides an interface for user processes to register timer notifications. This corresponds to the implicit execution architecture style described in [Garlan 1994]. This causes control to flow from the scheduler to the user process. The normal situation of resuming hibernation is not considered a control process under normal circumstances, because the user process cannot detect this operation. Finally, the scheduler communicates with CPU to suspend and resume the process. This results in data flow and control flow. CPU is responsible for interrupting the currently executing process and allowing the kernel to schedule another process.

3.2 memory Manager Architecture

The memory manager subsystem is responsible for controlling process access to hardware memory resources. This is done through a hardware memory management system that provides a mapping between process memory references and machine physical memory. The memory manager subsystem maintains this mapping on a per-process basis so that two processes can access the same virtual memory address and actually use different physical memory locations. In addition, the memory manager subsystem supports swapping. It moves unused memory pages to persistent storage so that the computer supports more virtual memory than physical memory.

3.2.1 Module structure Analysis

The memory manager mainly consists of the following three modules:

Architecture-related modules provide virtual interfaces for memory management hardware

Architecture-independent modules perform all each process mapping and virtual memory swapping. This module is responsible for determining which memory pages will be recalled in the event of a page error-since this policy is not expected to be changed, there is no separate policy module.

The system call interface module provides restricted access to user processes. This interface allows user processes to allocate and free storage, as well as perform memory-mapped file I / O.

3.2.2 from the point of view of data representation:

The memory manager stores the mapping of the physical address to each process of the virtual address. The mapping is stored as a reference in the task list data structure of the process scheduler. In addition to this mapping, other details in the data block tell the memory manager how to get and store pages. For example, executable code can use an executable image as backup storage, but the dynamically allocated data must be backed up to a system page file. Finally, the memory manager stores permissions and accounting information in this data structure to ensure system security.

3.2.3 data flow, control flow and dependencies

The memory manager controls the memory hardware and receives notifications from the hardware when a page error occurs-which means that there is a two-way flow of data and control between the memory manager module and the memory manager hardware. In addition, the memory manager uses the file system to support swapping and memory-mapped I / O. This requirement means that the memory manager needs to make procedure calls to the file system to store and retrieve memory pages from persistent storage. Because the file system request cannot be completed immediately, the memory manager needs to pause a process until the memory is swapped back. This requirement causes the memory manager to make procedure calls to the process scheduler. Similarly, because the memory mapping for each process is stored in the data structure of the process scheduler, there is a two-way data flow between the memory manager and the process scheduler. The user process can set a new memory map in the process address space and can register itself to notify the page error in the newly mapped area. This introduces the control flow from the memory manager to the system call interface module and then to the user process. Traditionally, there is no data flow from the user process, but the user process can retrieve some information from the memory manager using the select system call in the system call interface module.

3.3 Virtual file system architecture

Virtual file systems are designed to provide a consistent view of data stored on hardware devices. Almost all the hardware devices in the computer are represented by a common device driver interface. Virtual file systems evolve further and allow system administrators to install any one of a set of logical file systems on any physical device. Logical file systems promote compatibility with other operating system standards and allow developers to use different strategies to implement file systems. The virtual file system abstracts the details of physical devices and logical file systems and allows user processes to access files using a common interface without knowing which physical or logical system the files reside on.

In addition to traditional file system targets, the virtual file system is also responsible for loading new executables. This responsibility is accomplished by the logical file system module, which enables Linux to support multiple executable formats.

So in short:

Abstracts the details of physical devices and logical file systems to provide a common access interface.

Provides a general device driver interface.

Load a new executable program.

3.3.1 Module structure Analysis

It can be divided into four modules:

There are a large number of device drivers in the common driver abstract module because there are a large number of incompatible hardware devices. The most common extension of the Linux system is the addition of new device drivers. The device independent interface module provides a consistent view of all devices.

Logical file system module, each supported file system has a logical file system module.

The system independent interface layer provides a view of hardware resources independent of hardware and logical file systems. The module displays all resources using a block-oriented or character-oriented file interface.

The system call interface layer provides controlled access to the file system for user processes. The virtual file system exports only specific features to user processes.

3.4 Network Interface layer Architecture

The network subsystem allows Linux systems to connect to other systems over the network. Supports many possible hardware devices, as well as many network protocols that can be used. The network subsystem abstracts these two implementation details so that user processes and other kernel subsystems can access the network without knowing what physical devices or protocols are being used.

3.4.1 Module structure composition

The network device driver is responsible for communicating with the hardware device. Every possible hardware device has a device driver module.

Device-independent interface modules provide a consistent view of all hardware devices, so higher levels in the subsystem do not require specific hardware knowledge.

The network protocol module is responsible for implementing every possible network transport protocol.

The protocol-independent interface module provides interfaces independent of hardware devices and network protocols. This is the interface module that other kernel subsystems use to access the network without relying on specific protocols or hardware.

Make a long story short,

Network device driver to realize the Control of underlying hardware

The device independent interface layer provides the upper layer with a unified access interface to the underlying device driver layer.

The network protocol layer implements different network protocols.

The protocol independent interface layer is used to abstract and hide different hardware and different network protocols.

On how to conduct Linux kernel architecture analysis is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.