Looking inside the Linux kernel hierarchy: a view from the top of the mountain

You all know that many of Yuanlijun's articles are about the functions of the Linux kernel. Based on the principle of public accounts, we only talk about principles and convert complex codes into easy-to-understand texts and pictures. Finally presented to you. It can be said that Mr. Yuanli has never systematically sorted out the Linux kernel architecture for you from a large framework. Then the purpose of this article is to stand on the top of the mountain and look up.

Hierarchical framework of Linux system

From the picture we can divide it into two levels:

User space kernel space

At the bottom level is the user space, which is where the application is running. The upper layer of the user space is the commonly used gblic library for Linux memory management. Its function is to encapsulate the system call socket. It is a very unwise choice to directly use a large number of system call sockets without using the gblic library. Processes running in user space each have their own virtual address space, while the kernel has a separate address space.

The upper layer is the kernel space. The Linux kernel space is divided into three layers:

System call layer; it belongs to the lowest layer and provides a form of communication between user space and kernel space. Linux kernel: It should be more accurately said that it is the kernel code that is independent of the architecture. This universal code is applicable to any architecture. Architecture-dependent code: This part is generally called BSP. This kind of code is mainly introduced to be compatible with different platforms or processors.

The Linux kernel implements many important architectural properties. At a higher or lower level, the kernel is defined into subsystems. Linux can also be viewed as a whole, since it integrates all those basic services into the kernel. This is different from the microkernel architecture. The former will provide some basic services, such as communication, I/O, memory and process management, and more specific services are inserted into the microkernel layer. Each kernel has its own advantages, but this will not be discussed here.

Over time, the Linux kernel has become more efficient in video memory and CPU usage, and is very stable. And the most interesting thing about Linux is that it still has good portability despite these size and complexity. Linux is compiled to run on a large number of processors and platforms with different architectural constraints and requirements. A counterexample is that Linux can run on a processor that has a graphics memory management unit (MMU), or it can run on those processors that do not provide an MMU. The uClinux port of the Linux kernel provides support for non-MMUs.

Linux kernel architecture

The main components of the Linux kernel are:

System call socket process management video memory management virtual file system network stack device driver and hardware architecture related code.

(1) System call socket

The system call layer provides individual mechanisms to perform function calls from user space to the kernel. It is architecture dependent. Multiplexing and demultiplexing services are provided at this layer.

(2) Process management

The core of process management is process scheduling. In the Linux kernel, the unit of process scheduling is the process, and threads are equivalent to the concept of process for scheduling. The kernel provides application programming sockets through system calls. Such as: creating new processes (fork, exec), ending processes (kill, exit), and providing interfaces for controlling processes linux kernel transplantation steps, synchronizing processes and inter-process communication.

Process management also includes handling the need to share the CPU between active processes. The kernel uses the CFS completely fair scheduler, which is explained in detail in my previous article "Linux Completely Fair Scheduler CFS".

(3)Video memory management

Another important resource managed by the kernel is video memory. Another article by Yuanlijun, "Understanding Linux Video Memory Management, This Only Article" explains Linux video memory management in detail. In order to improve efficiency, the concept of virtual video memory is introduced. Video memory is managed according to the so-called video memory page form (usually a video memory page size is 4KB and 8KB, most of which are 4KB). In addition to Linux's methods of managing available video memory, there are hardware mechanisms used for math and virtual mapping. However, video memory management needs to manage more than just the 4KB buffer. Linux provides a concrete representation of the 4KB buffer, such as the slab allocator. These memory management modes use a 4KB buffer as a base, then allocate structures from it, and track memory page usage, such as which memory pages are full, which pages are not fully used, and which pages are empty. This allows the mode to dynamically adjust video memory usage based on system needs. In order to support the use of video memory by multiple users, sometimes the available video memory is consumed. For this reason, pages can be moved out of video memory and placed into the c drive. This process is called swapping because the pages are swapped from video memory to the hard drive. The source code for video memory management can be found in ./linux/mm.

(4)Virtual file system

Virtual File System (VFS) is a very useful aspect of the Linux kernel because it provides a universal interface representation for the file system. VFS provides a shield between system calls and file systems supported by the kernel. As shown on the right:

In VFS, it is a common API representation of functions such as open, close, read and write. Under VFS is the file system representation, which defines the implementation method of the lower-level functions. They are plugins for a given file system (more than 50 of them). The source code for the file system can be found in ./linux/fs. Below the file system layer is the buffer cache, which provides a common set of functions for the file system layer (independent of the specific file system). This caching layer optimizes access to chemical equipment by retaining data for a period of time (or pre-fetching the data later to make it available when needed). Beneath the buffer cache are device drivers that implement sockets for specific chemical devices.

(5) Network contract stack

The network contract stack is designed to follow the layered architecture of the simulated contract itself. Recall linux kernel transplantation steps, InternetProtocol (IP) is the core network layer contract under the transmission contract (commonly known as the transmission control contract or TCP). Inside TCP is the socket layer, which is called through the system call layer. The socket layer is the standard API of the network subsystem, which provides a user socket for various network contracts. From raw frame access to IP Contract Data Units (PDUs) to TCP and User Datagram Protocol (UDP), the socket layer provides a standardized way to manage connections and communicate data between various endpoints. The network source code in the kernel can be found in ./linux/net.

(6)Device driver

There is a large amount of code in the Linux kernel in device drivers, which can run specific hardware devices. The Linux source tree provides a driver subdirectory, which is further defined as various supported devices, such as Bluetooth, I2C, serial, etc. The code for the device driver can be found in ./linux/drivers.

(7) Architecture-dependent code

Although Linux is largely independent of the architecture it is running on, there are some elements that must be considered for the architecture to operate properly and achieve greater efficiency. The ./linux/arch subdirectory defines the architecture-dependent portions of the kernel source code, which contains various architecture-specific subdirectories (together making up the BSP). For a typical desktop system, the x86 directory is used. Each architecture subdirectory contains many other subdirectories, and each subdirectory focuses on a specific aspect of the kernel, such as booting, kernel, memory management, etc. This architecture-dependent code can be found in ./linux/arch.

Linux is also a dynamic kernel, supporting the dynamic addition or deletion of software components. Known as dynamically loadable kernel modules, they can be inserted on demand at boot time (the module is currently required for a specific device) or by the user at any time.

refer to

Yuanlijun referred to this article

The above is the detailed content of Looking inside the Linux kernel hierarchy: a view from the top of the mountain. For more information, please follow other related articles on the PHP Chinese website!