Linux Kernel type

Linux Kernel type-general Linux technology-Linux programming and kernel information. For details, refer to the following section. All solutions to complexity are based on a basic principle: Problem decomposition and cracking. That is to say
Into a certain number of sub-problems (or subsystems) with low complexity ),
Repeat this process as needed until each part is small enough to be solved, and the various methods are just like this principle.
Different applications.
There are three classic methods in computer science that are suitable for building large systems (I must first note that
).
1) Layer-the solution is divided into several parts, in which there is a bottom Layer of the problem domain
It provides the foundation for upper-level abstract work. The higher layer is built on its lower layer. OSI and
TCP/IP protocol stack is a well-known example of successful hierarchical software design. Hierarchical solution for Operating System Design
The solution may contain a level that can communicate directly with the hardware, and then provide abstract support for the higher level.
. In this way, a higher level can access disks, NICS, and other hardware, without understanding
Body details.
A feature of hierarchical design is to gradually build a vocabulary ). As the level increases
More and more powerful. Another feature of hierarchical design is that it can replace
Change to another level. Ideally, porting a hierarchical operating system only requires rewriting the underlying code. Pure Layer
The implementation speed of the sub-model may be slow, because the high-level must (indirectly) call a series of continuous low
Layers can process their own tasks-N layers call the N-1 layer, the N-1 layer calls the N-2 layer, and so on until the actual work in 0
The layer is processed. Then, of course, the result is passed back through the same path. Therefore, hierarchical design usually
It will include support for some high-level direct communications with some low-level communications; this increases the speed, but makes each layer
Secondary replacement is more difficult (because more than one senior will depend on the level you want to replace)
.
* Module-the Module hides a specific part of the function block behind the abstract interface. Features
Is to separate the interface and its implementation, so that a module can be entered without affecting other modules
Line change. In this way, the dependency between modules is limited to interfaces. The scope of the module is to try to reflect the solution domain
Some natural conceptual boundaries. Therefore, a pure modular operating system may have a disk subsystem module,
A memory management subsystem module. The main difference between pure modularization and pure hierarchical operating systems is:
Can be freely called by other modules, and there is no upper or lower layer between modules (in this sense, the module is
In a broad sense. From a pure point of view, a hierarchy is a module that can be called by one module at most.
Is its direct upper-layer module ).
* Objects-objects and modules are different, because they have different ways of thinking for beginners.
The implementation methods may also be independent. However, for our current purpose, the object is just a structured usage model.
Block Method. Components (component) are further improved as an object concept and are not yet designed in the operating system
Is widely used. Even so (according to our point of view), we do not have enough reason to divide it into modules
In the same category.
-1 emphasizes the hierarchical view of the kernel, and the unrelated level of the architecture lies above the level of the architecture.
(A more precise view is to add an additional level related to the architecture at the top layer. This is because the system calls the interface.
Located between the application and the kernel, and is architecture-related ). -2 emphasizes more modular internal
Core view.
From a reasonable expression level, both views are correct. However, we can also say that these two ideas are both incorrect. Me
You can use a large number of images to prove that the kernel complies with all the design principles you can point out, because it is
Extracted from many ideas. Simply put, the fact is that the Linux kernel is neither strictly hierarchical nor strict
It is not strictly any type, but mainly based on practicality (in fact, if you want
To summarize all the features of Linux from design to implementation in one word, it is the most practical ). Perhaps the most conservative
The idea is that the implementation of the kernel is modular, although these modules sometimes intentionally cross the module world to pursue speed
Limits.
In this way, the design of Linux takes into account both theory and practice. Linux does not ignore the design method. On the contrary
In the basic idea of development, the function of the design method is like a compiler: it is a powerful tool to complete the work. Select
Basic Design principles (such as objects) and full use of such principles do not allow any exceptions.
It is a good way to build a teaching system to illustrate these methods. However, for example
If you use it to achieve the Linux design goal, it will cause many problems. In addition, the Linux design goals do not include
To make the kernel a completely purified system. In order to achieve the design goal, Linux developers prefer to violate the rules
Current principle.
In fact, if it is correct for Linux, they are correct for all the most successful designs.
. The most successful and widely used practical system must be a practical system. Some developers try to find powerful
A special solution to all problems. Once they find this method, all the problems will be solved.
A successful design like a Linux kernel usually requires different levels of components and descriptions of the system.
Method. The result may not be clear or pure, but the mixed product is more pure than the same function.
The pure system is much more powerful and excellent.
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:
* Microkernel-in a microkernel, most kernels run as independent processes in a privileged state.
And communicate with each other through message transmission. In typical cases, each conceptual module has a process. Therefore, for example
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 execute system calls to complete the required tasks.
In these designs, the microkernel is often just a message forwarding station: when the system calls the module to the file system
When the module sends a message, the message is directly forwarded through the kernel. This method helps to isolate modules (sometimes
The module can also directly send messages to other modules ). In some microkernel designs, more functions, such as I/O
And so on. However, the most fundamental idea is to keep the microkernel as small as possible.
The kernel itself can be transplanted to the new platform. Other modules only rely on the micro-Internal
The core or other modules are not directly dependent on the hardware.
One advantage of microkernel design is to replace existing files with more efficient implementations without affecting other parts of the system.
The system module will be easier. We can even develop new system modules or replace them when the system is running.
The modules of existing modules are directly and quickly added to the system. Another advantage is that unnecessary modules will not be loaded into the internal
Therefore, the microkernel can use the memory more effectively.
* Monolithic kernel: A single kernel is a large process. It can be divided
Stem module (or level or other ). However, it is an independent Binary large image during running. Model
Inter-block 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 think that
The 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 such arguments often come to mind the past few years.
In the CPU field, the struggle between the CPU and the CISC. The successful modern CPU design involves all these two technologies, just like Linux
The kernel is the same as that of a single kernel. The Linux kernel is basically single, but it is not
Pure integrated kernel. The kernel module system introduced in the previous chapter introduces many advantages of the micro-kernel to the Linux
Kernel design. (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 do not approve of it, 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 core in a single way and run it in the initial space. This kind of decision avoids
Related work such as the message transmission architecture and computing module loading mode. (The kernel module system
.)
Another reason is the result of sufficient development time. Linux neither has the development time limit nor comes from the city
Release progress of field pressure. All the restrictions only apply to kernel modification and expansion. Single Kernel Design
Full modularization is implemented internally, and modification or addition under such conditions is not difficult. And the problem is still
There is no need to rewrite the Linux kernel for the pursuit of unproven small growth in Maintainability
Do not emphasize the following point of view: the loss rate is not worthwhile for this benefit ). The following sections will detail
The development time is sufficient.
If Linux is a pure microkernel design, it will be easier to transplant it to other architectures. In fact, there are
Some micro-Kernels, such as the Mach micro-kernel, have successfully proved the advantages of this portability. The actual situation is,
Although Linux kernel porting is not very simple, it is never impossible: the approximate number is, to a brand new
Typical porting in the architecture requires 30 000 to 60 000 lines of code, plus less than 20 000 lines of driver
Sequential Code (not all porting requires new driver code ). A rough calculation, a typical porting
About lines of code are required on average. This is what one programmer or at most one program group can do.
, Which can be completed within one year. Although this requires more code than the porting of the microkernel, Linux's support will
It will be suggested that such a Linux kernel porting version can use the underlying hardware more effectively than the microkernel, so the porting process
The extra work in 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.
The latter thinks that the microkernel is the future development trend. However, because of the single mode (in most cases) in Linux
The running status is good, and kernel porting is relatively difficult, but it does not obviously hinder the work of the programmer group,
They have successfully transplanted the kernel to most of the existing real systems, not to mention Palm-mounted computers.
As long as many features of Linux are still worth transplantation, new versions will emerge.