Linux Kernel Tour __linux

I don't think I'm a master on Linux because my shell doesn't reach the level of C language, and my kernel development focuses on device-driven development. But I am convinced that I am now an entry-level person who can quickly locate and then give the right guidance and answers when confronted with a problem.

Is the Linux kernel difficult?

At the beginning of the contact, and now is completely two kinds of answers. Before learning Linux, I did a few years of SCM development, the basic 51 series, MSP430 series and so on. This provides me with a deep foundation for understanding Linux's hardware operations. Because for the CPU, the most basic part is the same, such as clock settings, watchdog, interrupt, GPIO, serial port and so on. These in the SCM development, it is entirely to write their own drive to adapt to different requirements. So, on the move to Linux, My Learning Clue, is based on the Linux system hardware operation as the main line. For example, I want to know how Linux operates the CPU clock, I need to know what the Linux API is connected to the final register through what process.

Continuous exploration, recording, understanding, and finally the Linux kernel with the initial understanding.

In the study, the feeling and SCM development, the biggest difference is that Linux has the concept of interface. In the previous development process, never the CPU driver controller and peripheral device drive separate to operate, and in Linux has the concept of bus. One end of the bus is attached to the controller, one end attached to the peripheral drive. The bus interface masks different device drivers on different CPUs, providing a unified interface for peripheral drive development.

At the beginning of my study, I dreamed that I could write a bus driver, but when I looked closely at the kernel source, I found that the Linux kernel covered almost all of the interface. and the corresponding CPU bus controller driver, most of the CPU developers to provide. For a primary driver, you can skillfully use the bus interface, the development of peripheral device drivers can meet the requirements, do not have to pay attention to the other side of the specific implementation.

However, I have studied hardware, chip procurement, circuit design, PCB painting have done, so I think I should understand more in-depth. In the device-driven development, the most important thing is to understand the concept of device,bus,driver. If you understand the relationship between the three, then the device driver will understand half. Other parts of the device driver are the basic concepts in the kernel, such as blocking, synchronizing, task, interrupt, and user-layer interfaces.

I want to learn the kernel, in addition to starting from the hardware, but also from the user layer interface to start. After all, not many people have the basis of hardware, so if you are familiar with the Linux application software, then the best way is to start from the user layer interface. such as device nodes, proc files, sys files, netlink,uevent, system calls, and so on. When you can skillfully use different interfaces, to operate hardware devices, the Linux kernel is the time to get started.

Now that you are getting started, at this time, all the current bus drivers can be used to achieve the point. What is the next goal? Memory management, DMA management, interrupt management, file system management, startup process. This part is the only way to the core of Linux. Memory management helps us to understand the advantages and disadvantages of different memory allocation APIs, the characteristics of different memory allocation algorithms, as well as the real and virtual storage space distribution in Linux and so on. DMA Management allows us to understand the DMA startup process, using methods, and this part is also dependent on hardware. Interrupt management to help us understand interrupted organization and invocation routes, and interrupt usage and attention factors. File System Management allows us to drill down into the VFS layer of Linux, where all operations can see the interface of the VFS. Start process, we can know bootloader boot Linux kernel parameters and boot, hardware initialization order, driver load sequence, rootfs mount and so on.

To this step, I think the Linux kernel learning, can reach about 60%. The last part is Linux kernel scheduling and network protocol stack. These two parts are the most important part. Task scheduling is the core of any operating system, and the advantages and characteristics of a system can be obtained by task scheduling. As for kernel scheduling, I want to first understand how a process is created and run. This time, it involves the Linux system executable program format, such as the Elf. Why a program, called in the shell, can be executed. First look at the BusyBox shell code, look at the system call code, look at the process of kernel creation process, and so on. How the multiple created processes are scheduled in the kernel. I was told a few Linux scheduling algorithms in college, but looking at the code and the implementation process in person is another step forward. If you have seen other system code, such as VxWorks, you can compare the scheduling differences between the two systems, and the difference between the application areas (of course, not all of the scheduling difference).

The network protocol stack is a complex project. is also my lack of place. Not too much involved, I want to know how the socket is created, how to block, if the communication, the algorithm in the stack and so on. Perhaps the network protocol stack is not necessary in the work, but the Linux master must.

Like many predecessors, also feel the kernel of makefile and kconfig more important, they are digging the core clues. In addition, I think that learning the kernel, should start from their own point of interest, such as what you want to know the most questions, and then go to track. Then, when you understand this process, your knowledge base has formed a line, possibly in the process, involves a lot of other do not know knowledge, so let him stay in your imagination, what you think he is like, then he is like. The key is to grasp the main line and grasp the transfer process from the top down. So you have a net when you have more than a certain number of lines in your knowledge base. Several points on the line may be the first thing you don't know. If you are knitting two lines together, from a higher perspective to re-examine and summarize the past work, there will be more understanding. When your web becomes more woven, and finally fills all aspects of the kernel, a new milestone is reached. After that, you can hang your own bells online, or you can optimize some algorithms to make the links between lines more orderly and efficient.

I don't recommend to know every bell on the line, it takes too much time. What we want to master is the net. If you want to add a bell to the web, you can quickly navigate to the desired location. Even, I don't know where to put it, but I can quickly navigate to that location through a clue on the internet and then learn the connection method.

The Linux kernel is a web, where the hierarchy and interfaces are fascinating.

If the network does not have the answer you want, then the source is the best solution.

Come on, let's go.