Basic Linux kernel knowledge

Basic knowledge about the kernel in Linux-general Linux technology-Linux programming and kernel information. For details, refer to the following section. Most Linux instances are single-core

The operating system kernel may be a micro kernel or a single kernel (which is sometimes called a macro kernel Macrokernel ). These terms are defined as follows in a similar encapsulation:

L Microkernel kernel )?? In the microkernel, most kernels run as independent processes in a privileged state and communicate through message transmission. In typical cases, each conceptual module has a process. Therefore, if there is a system call module in the design, there must be a corresponding process to receive system calls and other processes (or modules) that can execute system calls) communication to complete the required tasks.

In these designs, the microkernel is often just a message forwarding station: when the system call module sends a message to the file system module, the message is directly forwarded through the kernel. This method helps isolate modules. (In some cases, the module can directly send messages to other modules .) In some microkernel designs, more functions, such as I/O, are also encapsulated in the kernel. However, the most fundamental idea is to keep the microkernel as small as possible, so that the entire kernel can be transplanted to the new platform by porting the microkernel itself. Other modules depend only on the microkernel or other modules, and do not directly rely on hardware.

One advantage of the microkernel design is that it is easier to replace the existing file system modules with more efficient implementations without affecting other parts of the system. We can even directly and quickly add new system modules or modules that need to replace existing modules during system operation. Another advantage is that unnecessary modules will not be loaded into the memory, so the microkernel can use the memory more effectively.

L Monolithic kernel )?? A single kernel is a large process. It can be divided into several modules (or layers or others ). However, it is an independent Binary large image during running. Inter-module communication is implemented by directly calling functions in other modules, rather than passing messages.

Supporters of a single kernel claim that the message passing overhead of the micro kernel has caused a loss of efficiency. Supporters of the microkernel believe that the increased flexibility and maintainability of the kernel design can compensate for any loss.

I don't want to discuss these issues, but it must be noted that it is very interesting that this debate often reminds me of the struggle between the CPU and the CISC in the past few years. The successful modern CPU design involves all these two technologies, just as the Linux kernel is a mix of micro-core and single-core products. The Linux kernel is basically single, but it is not a pure integrated kernel. The kernel module system introduced in the previous chapter introduces many advantages of the micro-kernel into the single-kernel design of Linux. (By the way, I have considered an interesting situation, that is, the Linux kernel module system can convert the system kernel into a simple microkernel design without passing messages. Although I disagree, it is still an interesting idea .)

Why should Linux be a single kernel? One aspect is the historical reason: from Linus's point of view, it is quite easy to organize the kernel in a single way and run it in the initial space. This decision avoids the work related to the message transmission architecture and computing module loading mode. (The kernel module system has been continuously improved in the following years .)

Another reason is the result of sufficient development time. Linux has no development time limit or release progress that is under pressure from the market. All the restrictions only apply to kernel modification and expansion. The single design of the kernel is fully modularized internally. modifications or additions under such conditions are not difficult. The problem is that there is no need to rewrite the Linux kernel in order to pursue the small growth of unconfirmed maintainability. (Linus has repeatedly stressed the following points: the loss rate is not worthwhile for this benefit .) Part of the content in later sections will review the effect of sufficient development time in detail.

If Linux is a pure microkernel design, it will be easier to transplant it to other architectures. In fact, some microkernels, such as the Mach microkernel, have successfully proved the advantages of this portability. The actual situation is that Linux kernel porting is not very simple, but it is never impossible: the approximate number is, typical porting to a brand new architecture requires 30,000 to 60,000 lines of code, plus less than 20,000 lines of driver code. (Not all porting requires new driver code .) After rough calculation, I estimate that a typical porting requires an average of 50,000 lines of code. This can be done by one programmer or at most one program group within one year. Although this requires more code than the transplantation of the microkernel, the Linux supporter will propose that such a Linux kernel porting version can more effectively use the underlying hardware than the microkernel, therefore, the extra work in the porting process can be compensated for the improvement of system performance.

This kind of special design trade-offs can not be easily achieved. The single-core Implementation Strategy openly violates the traditional view, and the latter thinks that the microkernel is the future development trend. However, because a single mode (in most cases) runs well in Linux, and kernel porting is relatively difficult, it does not obviously hinder the work of the programmer group, they have enthusiastically transplanted the kernel to most of the existing real systems, not to mention some seemingly unrealistic targets like the head-on computers. As long as many features of Linux are still worth transplantation, new versions will emerge.