Detailed analysis of Linux operating system source code (2)

Detailed analysis of Linux operating system source code (2)-Linux general technology-Linux programming and kernel information. The following is a detailed description. Chapter 2 initial recognition of code generation

This chapter first introduces the Linux kernel source program at a higher level. These are some of the basic features that everyone cares about. Then, we will briefly introduce some actual code. Finally, we will introduce how to compile the kernel.

　　 2.1 features of the Linux kernel source program

In the past, the Linux kernel has been implemented in both C and assembly languages. These two languages need to be balanced: C language code has good portability and easy maintenance, while assembly language programming is faster. The Assembly Language is generally used only when speed is a key factor or some special requirements (for example, directly communicating with memory management hardware) due to platform-related features.

As we have actually done, even if the kernel does not use the object feature of C ++, some kernels can be compiled under g ++ (gnu c ++ compiler. Compared with other object-oriented programming languages, the cost of C ++ is relatively low, but for Kernel developers, this is already too much.

Kernel developers constantly develop programming styles, forming a unique feature of Linux code. This section discusses some of these issues.

　　 2.1.1 use of gcc features

The Linux kernel is designed to be compiled using the gnu c compiler gcc instead of any C compiler. The gcc feature is sometimes used for kernel code. This book will introduce some of the features.

Some gcc-specific code is simply extended using the gcc language. For example, the inline keyword can be used to indicate inline functions in C (not just C ++. That is to say, the called function in the Code is expanded every time the function is called, thus saving the overhead of the actual function call.

Generally, code writing is complicated. For some types of input, gcc can produce code execution that is more efficient than other input. Theoretically, the compiler can optimize two equivalent methods with the same functions and get the same results. Therefore, writing code is irrelevant. But in fact, writing the code in some way is much faster than writing the code in other ways. Kernel developers know how to generate more efficient code execution, which is constantly reflected in the Code they write.

For example, consider the goto statements that are frequently used in the kernel-in order to improve the speed, the kernel often uses a large number of such statements that are generally avoided. In less than 500 lines of code contained in this book, there are more than goto statements, about one for every 80 lines. In addition to assembly files, precise statistics are close to one goto statement per 72 rows. To be fair, this is the result of a biased choice: one of the reasons for such a high proportion is that this book involves the core of the kernel source program, where the speed needs to be prioritized over other factors. The ratio of the entire kernel is about one goto statement per 260 lines. However, this is still the most frequently used goto that I have seen since I no longer use Basic programming.

The features that code must be restricted by a specific compiler are not only very different from the development of common applications, but also different from the development of most kernels. Most developers write code in C language to maintain high portability, even when writing an operating system. The advantage of doing so is obvious. The most important thing is that programmers can change the compiler at any time when a better compiler is available.

The full dependency of the kernel on the gcc feature makes it more difficult to port the kernel to the new compiler. Linus recently expressed his opinion on this issue in the kernel-related email list: "Remember, the compiler is just a tool ." This is a good expression of the basic idea that relies on the gcc feature: the compiler is just to complete the work. If compliance with standards does not meet the work requirements, it is not a problem with the work requirements, but a problem with the standard dependency.

In most cases, this idea is unacceptable. In general, to ensure consistency with the language standards, developers may need to sacrifice certain features, speeds, or other relevant factors. Other options may cause a lot of trouble for later development.

However, in this particular case, Linus is correct. Linux Kernel is a special case because its execution speed is much more important than portability to other compilers. If the design goal is to write a kernel that is portable and does not require fast running, or compile a kernel that anyone can use their favorite compiler to compile, the conclusions may be different. These are not the design goals of Linux. In fact, gcc can generate code for almost all CPUs that can run Linux. Therefore, gcc dependency is not a serious obstacle to portability.

In chapter 2, we will describe the kernel design objectives in detail.