Macro kernel and micro kernel, Linux kernel and UNIX Kernel

 

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:

 

 

 

Single Kernel: Also knownMacro Kernel. The kernel is implemented as a large process and runs in a separate address space at the same time. All kernel services run in one address space and call functions directly between them, which is simple and efficient. Micro-kernel: functions are divided into independent processes, which communicate with each other through IPC. A high degree of modularization does not affect the failure of one service. Linux is a single-core structure, while absorbing the advantages of the micro-kernel: modular design, support for dynamic loading of kernel modules. Linux also avoids the design defect of the microkernel, so that everything runs in the kernel state and calls functions directly without passing messages.

Most Linux instances are single-core.

 

 

Microkernel(Microkernel kernel)-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.

Single Kernel(Monolithic kernel)-a single kernel is a 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.

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 run in a separate address space in the form of complete and separate executable blocks.

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 each process can run on 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 is 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. A single kernel is implemented as a separate large process and runs in a separate address space at the same time. Therefore, such a kernel is usually stored on a disk in the form of 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 functions, which is no different from the user space. Supporters of this model think that a single module is simple and high-performance. Most Unix systems are designed as single modules.

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 of which is called a server. Ideally, only servers that strongly request privileged services run in privileged mode, and other servers run in user space. However, all servers remain independent and run in their respective address spaces. Therefore, it is impossible to directly call functions like a single module kernel, but to process 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 the failure of one server and the other.

Similarly, a modular system allows one server to be switched out for another server. Because the IPC Mechanism has more overhead than function calls and involves context switching between kernel space and user space, message transmission takes a certain period, simple function calls in a single kernel do not have these overhead. Based on this, the actual microkernel system allows most or all servers to be in the kernel, so that you can directly call functions to eliminate frequent context switches. Windows NT kernel and Mach (components of Mac OS X) are typical micro-kernel instances. Both Windows NT and Mac OS X do not allow any microkernel servers to run in the user space in their latest versions, which violates the original design of the microkernel.

Linux is a single kernel, that is, the Linux kernel runs in a separate kernel address space. However, Linux has taken the essence of the micro-kernel: it is proud of its modular design, preemptible kernel, support for Kernel threads, and the ability to dynamically load kernel modules. Moreover, Linux also avoids the performance loss defect in its microkernel design, so that everything runs in the kernel state and calls functions directly without passing messages. 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 realized that they should not ignore the Unix background (especially the Unix API ). Since Linux is not based on a specific UNIX, Linus and his partners can choose the best solution known for each particular problem-sometimes, of course, some new solutions can also be created. 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, some kernel code can be dynamically detached and loaded as needed.

· 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 the ability to give priority to tasks running in the kernel. Among other UNIX products, only Solaris and IRIX support preemption, but most traditional UNIX kernels do not support preemption.

· Linux's implementation of thread support is interesting: the kernel does not distinguish threads from other general processes. For the kernel, 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 poorly designed, such as streams, and ignores outdated standards that are not actually used at all.

· Linux represents the essence of freedom. The existing Linux feature set is the result of the free development of the Linux public development model. If a feature has no value or has 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 aimed at problems in reality, it has been well designed and implemented correctly and concisely. 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.

 

 

 

The following is an introduction to the macro kernel from Wikipedia.

 

 

 

 

 

Macro KernelAlso knownSingle KernelIn EnglishMonolithic Kernel.

Macro KernelIs a kernel architecture of the operating system. This architecture features that the entire kernel program runs as a kernel space and as a supervisor mode. Compared with other types of operating system architectures, such as microkernel architecture or hybrid kernel architecture, these kernels define an advanced virtual interface that covers the entire computer hardware, these descriptions combine into a set of hardware descriptions, and sometimes some system calls are attached, so that one or more modules can be used to implement various operating system services, such as process management, concurrency control, and memory management.

Even if some macro kernels split their overall operation into several service modules and let each module operate independently, their operating system code is still highly closely related, it is difficult to change to another type of operating system architecture. In addition, all modules run in the same addressing space. If a module has errors or bugs, the operation of the entire operating system may be compromised. In turn, if the operating system of the macro kernel architecture is well developed and designed, and is highly reliable after testing and verification, the software components in the operating system are highly tight, this will be extremely efficient in the low-level operation of the system.

 

Load-able modules

 

Currently, most operating systems that adopt the macro kernel architecture, such as OpenVMS, Linux, FreeBSD, and Solaris, can be loaded dynamically in the running stage) unload can run modules. However, these modules belong to the level of binary code, or the image level, rather than the level of the kernel architecture. Even if the macro kernel is modularized, it will not be confused with the kernel of the microkernel or mixed kernel architecture, because the modules of the microkernel and mixed kernel belong to the level of the system architecture.

In practice,Dynamic Loading/unloading ModuleThis is equivalent to using a simple method to flexibly control the operating system kernel in the running state. If there is no Dynamic Loading/Unloading Mechanism, to make any adjustments or changes to the operating system kernel, you must restart the system to make the changes. Therefore, modularization is inevitable and necessary, so that the kernel functions can be easily expanded and extended. In addition, it can also reduce the operating burden of hardware in a timely manner.

In addition, in order to minimize the kernel space of some monolithic operating systems, dynamic loading/uninstallation mechanisms are also used to achieve this goal.

 

Some operating system examples of macro kernel architecture

• Unix-like Kernel
  • Linux
  • Syllable
  • UNIX Kernel
    • BSD
    • Solaris
• DoS
  • Dr-DoS
  • MS-DOS
    • Microsoft Windows 9x series (95, 98, 98SE, me)
• Mac OS (from the initial version to Mac OS 8.6)
• OpenVMS

 

Figure 1 macro kernel architecture