Micro kernel, single kernel and Linux

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 (microkernel)-In the microkernel, most kernels run as separate 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 only a message forwarding station: when the system call module sends messages to the document system module, messages are 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 only by porting the microkernel itself. Other modules depend only on the microkernel or other modules, and do not directly rely on hardware.
One of the advantages of microkernel design is that it is easier to replace existing document 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 modules that are not needed will not be loaded into the memory, so the microkernel can use the memory more effectively.
L monolithic kernel-a single kernel is a very large process. It can be divided into several modules (or layers or others ). However, it is a single 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, interestingly, 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 any of these two technologies, just as the Linux kernel is a mix of micro-kernel and single-kernel products. The Linux kernel is basically single, but it is not a pure integrated kernel. The kernel module system described 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 that does not transmit messages. Although I disagree, he 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 R & D time. Linux has no R & D time limit or release progress that is under pressure from the market. Any restriction is limited to modifying and expanding the kernel. 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 the subsequent sections will carefully reconsider the effect of sufficient R & D time.
If Linux is a pure microkernel design, it will be easier to transplant it to other architectures. In fact, some micro-Kernels, such as the Mach micro-kernel, 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 any 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 within 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 impede the work of the programmers, 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.

Another text

Comparison between Linux kernel and traditional UNIX Kernel
All UNIX kernels are of the same origin and provide the same API. modern Unix kernels have many design similarities.

The Unix kernel is almost always an inseparable static executable block (file ). That is to say, they must be complete, single

An executable block is run in a separate address space.

Almost all UNIX kernels require the hardware system to provide page mechanisms to manage memory. This page mechanism can enhance the protection of memory space and ensure that

Processes can run in different virtual address spaces.
Comparison between single-core and micro-core Designs
The operating system kernel can be divided into two major design camps: single kernel and micro kernel (kernel outside the third camp, mainly used in scientific research systems,

But it is also growing in the real world ).

A single kernel is a relatively simple design in the two camps. before 1980, all kernels were designed as single kernels. The so-called in-ticket

The core is implemented as a separate large process and runs in a separate address space at the same time. Therefore

The kernel is usually stored on disks as a single static binary file. All kernel services run in such a large kernel space.

The communication between kernels is insignificant, because everyone is running in the kernel state and in the same address space: the kernel can directly call the function.

Number, which is no different from the user space. Supporters of this model think that a single module is simple and high-performance. Most Unix

The system is designed as a single module.

On the other hand, the microkernel is not implemented as a separate large process. On the contrary, the features of the microkernel are divided into independent processes,

Each process is called a server. Ideally, only servers that strongly request privileged services run in privileged mode.

All servers run in the user space. However, all servers remain independent and run in their respective address spaces. Therefore, it is impossible

The single-module kernel calls functions directly, but processes micro-kernel communication through message transmission: The system uses the inter-process communication (IPC) mechanism,

Therefore, various servers exchange messages and exchange "services" through the IPC Mechanism ". Each server independently and effectively avoids a service.

The failure of the device causes another disaster.

Similarly, a modular system allows one server to be switched out for another server. Because the IPC Mechanism has more overhead than function calls,

Because it involves context switching from the kernel space to the user space, message transmission takes a certain period of time.

Function calls do not have these overhead. Based on this, pay for the actual microkernel system so that most or all servers are located in the kernel. In this way

Functions can be called directly to eliminate frequent context switches. Windows NT kernel and Mach (components of Mac OS X) are micro-kernels.

. Both Windows NT and Mac OS X do not allow any microkernel server to run in the latest version.

This violates the original intention of the microkernel design.

Linux is a single kernel, that is, the Linux kernel runs in a separate kernel address space. However, Linux uses the microkernel

Essence: it is proud of its modular design, preemptible kernel, support for Kernel threads, and dynamic loading of kernel modules. Not only

In this way, Linux also avoids the performance loss defect in its microkernel design, so that everything runs in the kernel state and calls functions directly without eliminating the need

Information Transmission. So far, Linux is a modular, multi-threaded operating system and the kernel itself can be scheduled. Pragmatism once again prevails.

When Linus and other kernel developers design the Linux kernel, they are not completely different from the Unix kernel. They fully understand

To avoid ignoring the Unix background (especially the Unix API ). Linux is not based on a specific UNIX, Linus and

Partners can choose the best solution known to each specific problem-sometimes, of course, they can also create some new

Solution. The following is an analysis and comparison of kernel features of Linux kernel and UNIX variants:
· Linux supports dynamic loading of kernel modules. Although the Linux kernel is also a single kernel, it allows dynamic dismounting and

Load some kernel code.

· Linux supports the Symmetric Multi-processing (SMP) mechanism. Although many unix variants also support SMP, traditional UNIX does not support this

Mechanism.

· Preemptive ). Unlike traditional UNIX, the Linux kernel has tasks that can be run in the kernel.

Priority execution capability. Among other UNIX products, only Solaris and IRIX support preemption, but most traditional UNIX kernels do not

Supports preemption.

· Linux's implementation of thread support is interesting: the kernel does not distinguish threads from other general processes. For the kernel, all

All processes are the same-only some of them share resources.

· Linux provides device-class object-oriented device models, hot swapping events, and user-space device file systems.

(Sysfs ).

· Linux ignores some UNIX features that are considered to be poorly designed, such as streams, and ignores

Outdated standards that will not be used.

· Linux represents the essence of freedom. The existing Linux feature set is the result of the free development of the Linux public development model. For example

If a feature has no value or poor creativity, no one will be forced to implement it. On the contrary, during the development of Linux

A commendable pragmatic attitude has been formed: any change must be targeted at the problems that exist in reality. It has been well designed and positive.

Concise implementation. As a result, many other features of modern Unix systems, such as the kernel paging mechanism, are introduced without hesitation.

.

Regardless of the differences between Linux and UNIX, it is deeply labeled as UNIX.