Macro talked about macro kernels and microkernels, and blew a wave of Linux

Hey guys, this is the programmer cxuan, welcome to my latest article.

Original link: Macro talked about macro kernel and micro kernel, and blew a wave of Linux

The kernel is a very important part of the operating system, and it is also the core of the operating system. The kernel manages system resources. The kernel connects applications upwards and hardware downwards. It is a bridge between applications and hardware.

Kernels can be further divided into macrokernels and microkernels .

The biggest difference between the macro kernel and the micro kernel is that the user services and kernel services of the macro kernel are stored in the same address space, and they are all managed by the kernel, while the user services and kernel services of the micro kernel are stored in different addresses. In space , the following figure can explain this very well.

image-20211027222024063

In fact, the translation of the macro kernel here is a bit far-fetched. In fact, it should be called a single core or a single core. In this single-core design, the kernel is a large whole, which can be said to be a large process. In this large process, all kernel services run in one address space, and there are few call links between functions, and direct Communication is simple and efficient .

The functions of the microkernel are divided into independent processes, and the processes communicate through IPC , which is highly modular, and the failure of one service will not affect another service. However, due to the influence of modularity, the call links between functions are long, and processes do not communicate directly, but communicate with each other through kernel services.

In terms of kernel size , the size of the microkernel is smaller and only includes services related to user processes, while the size of a single core is much larger than that of the microkernel, which is easy to understand, because the macrokernel integrates too many services and services. drive.

In terms of execution efficiency , the execution efficiency of the microkernel is relatively slow because it involves cross-module calls, while the execution efficiency of the macrokernel is high because functions are called directly.

After the microkernel is modularized , it is easy to expand, because the kernel space and the user space are isolated from each other, and the data in the kernel will generally not be affected after the application crashes in the user mode (applications running in the user space). Macro kernels are less scalable.

After these descriptions above, it is easy to imagine the characteristics of macrokernels and microkernels as monolithic architectures and microservices architectures in software development .

The biggest feature of the monolithic architecture is that it is convenient to call functions, and there is almost no call link. One project solves all problems. The project includes database drivers, various interceptors, controllers, and permission control, and the scalability is very poor.

The call link between the microservice architectures will be relatively long, and the responsibilities between modules are separated and dependent on each other, such as permission control module, routing module, and bus communication module. Extensibility is relatively strong.

These two different kernel structures have different proponents, just as some people think that the monolithic architecture is good, and some people think that the microservices architecture pattern is good.

It's like arguing about programming languages, which one do you say is better, Python, Go, Java, or any other language? Whichever is better, he will end up jokingly calling PHP the best language in the world . So, these arguments are moot, but it's interesting that they are often reminiscent of the battle between RISC and CISC in the CPU space in previous years.

Modern successful CPU designs include either of these two technologies, just as the Linux kernel is a hybrid product of a microkernel and a macrokernel. Some people may think that Linux is not just a macro kernel structure, but in fact Linux is not just a pure integrated kernel.

Why does Linux use a single-kernel (here called a single-kernel is somewhat appropriate) structure? I guess there are a few factors below.

From Linus' point of view, the development and selection of a single core is easier because the work related to message passing architecture, computing module loading methods, etc. is avoided. And the reason for the birth of Linux is that Linus was very dissatisfied with MINIX (a kind of UNIX-like operating system) that was only allowed to be used in education, and Linus was originally very interested in operating systems, so he started to write Linux operating systems, so I think at that time Linus developed Linux out of hobby, without careful design and without considering its extensibility. Of course this is just my humble guess.

This is the same as our graduation design in college. Do you consider scalability for the system you made in your graduation design? Unless you want to do it as a product, but why?

Another reason is ample development time. Linux has no development time limit and no release schedule. Any restrictions can only modify and extend the kernel alone. The single design of the core is completely modular inside, and it is not very difficult to modify or add in this case. The problem is that there is no need to rewrite the Linux kernel in pursuit of a small increase in unproven maintainability. Linus has repeatedly emphasized the point that the loss of speed for this benefit is not worth it.

Linux is a macro-kernel structure that draws on the essence of microkernels. Linux supports modular design, preemptive kernels, support for kernel threads, and the ability to dynamically load kernel modules. Not only that, but Linux avoids the performance penalty of its microkernel design, allowing everything to run in kernel mode, calling functions directly without message passing.

So to sum up, Linux is a modular, multi-threaded and kernel-schedulable operating system.

Modular design: Linux supports dynamic loading of kernel modules, although the Linux kernel is also a single core, it allows some kernel code to be removed and loaded dynamically when needed.

Preemptibility: The Linux kernel supports preemption. Unlike traditional UNIX, the Linux kernel has the ability to allow tasks running in the kernel to execute preferentially. Of the various UNIX products, only Solaris and IRIX support preemption, but most legacy UNIX kernels do not.

In Linux, pragmatism is perfect. If a feature has no value or a bad idea, it won't start implementing it. On the contrary, in the development of Linux, a commendable pragmatism has developed: any changes must be aimed at real problems in reality, and need to be completely designed and implemented correctly and concisely.

If Linux was a pure microkernel design, porting to other architectures would be easier. The reality is that Linux kernel porting, while not trivial, is by no means impossible.

Finally, I would like to recommend to you that there are many hard-core articles in my own Github , which will definitely help you.

Guess you like

Origin blog.csdn.net/qq_36894974/article/details/121094930