Embedded System Linux kernel Development Practice Guide (ARM platform) book reviews
I am deeply touched by the heavy book embedded Linux kernel Development Practice Guide (ARM platform. This book was finally published by my editors and the joint efforts of many Parties. Looking at the exquisite finished book, I felt unsatisfied and excited.
On the cover, I wrote the words "the technical director resigned for one year and wrote carefully". During the editing process, I also felt the painstaking efforts of the author all the time, mr. Wang honghui reflected his 12 years of work experience and learning experience in this 1156-page book. The words and sentences in "Origin" can also help me understand the transformation from "sorrow and Sorrow" to "integration" during my years of dealing with Linux.
How many 12 years can a person have in his/her life! This book is the author's growing book on the Linux front, this paper introduces the concept, organizational structure, working principle, software and hardware design process, development and debugging methods, as well as the development methods and skills of Embedded Linux, and lists the practical cases of many authors. For beginners who have just started, it can help you get started quickly without detours. For engineers who have been in the industry for many years, it can help you avoid difficulties. For experienced experts, it is also a platform for communication and discussion.
Maybe you are familiar with four core components of Linux kernel: "Memory Management", "Process Management", "File System", and "device driver, but do you understand their principles and implementations?
"Linux uses a relatively simple mechanism called 'page frame bitrate size' at the early stage of system startup to manage physical memory. This mechanism is for all Memory nodes in the system) each page frame (PAGE) includes a page in the memory hole allocated with a bit as its bit code. If the bit code is 1, the corresponding page does not exist or is being used, 0 indicates that the corresponding page is idle and can be reassigned. The page frame size of each memory node is page-aligned, the page frame code table of all Memory nodes is stored on the page consecutively starting from the next page of the memory space of the kernel, as shown in 18-4 (note: the frame code and kernel of the memory page must be placed in a memory bank of the memory node No. 0; otherwise, the system cannot start ). The startup code first sets all page frame codes to 1, and then clears the page frame codes corresponding to the actual physical memory in the memory node to 0, then, set the page frame code corresponding to the memory space occupied by initrd, kernel, page frame code table, and page table to 1 to protect the memory from being damaged, in this way, the physical memory pages whose page frame code is 0 can be allocated by the memory allocation function." (Excerpt from section 18.4.1)
Have you ever encountered the same problem before? Have you ever been confused? Do you have an epiphany when I see Miss Wang's incisive analysis? This point is the accumulation of many years of work experience by Mr. Wang, citing a trendy word, which is truly "original!
"The operation functions of the two drivers on the console device are completely different. The operation functions of the console driver called by printk () are specified by the function pointer in the struct console structure, generally, you only need to implement the write () method, and the operation function of the driver corresponding to the/dev/console is specified by the function pointer in the struct tty_driver structure, generally, the operation methods described in section 25.2.6 must be implemented. The implementation mechanisms of the other two drivers are also different. When printk () calls the write () method to output characters from the console, the write () method will exit until all the characters are sent, does not sleep the process calling it while waiting, and takes the initiative to let out the CPU time slice, because the printk () function (lele_init () needs to be called during the system startup process () after the function is executed, the kernel information can be output from the console. At this time, no other processes have been created in the system. Only the starting process is process 0, and it is impossible to sleep, therefore, when writing drivers or other kernel programs, make sure to use the printk () function as little as possible, and do not use printk () in the runtime loop program (), otherwise, the system performance will be greatly reduced, while the implementation mechanism of the read/write method of the driver corresponding to/dev/console is different from that of the printk () driver. You can read tty_write () carefully () function to understand its implementation mechanism." (Excerpt from section 25.2.10)
In the previous learning process, have you noticed that the operation functions of the two drivers have the above differences? Instructor Wang took you into the mysterious situation of "Linux device drivers" and unveiled the device drivers on the console for you to see clearly!
"In Linux, all variables related to a specific processor are prefixed with 'per _ CPU _ 'before the variable name. We call it 'processor-specific variable ', for example, per_cpu _ rcu_data. in systems that support config_smp, all processor-specific variables with the prefix 'per _ CPU _ 'have a specific implementation in each processor. For example, assume that the system has nr_cpus processors, then each processor dedicated variable has nr_cpus + 1 (. data. percpu stores the original variable of all the dedicated variables of the multi-processor. It is independent of the variable zone of each processor and stores the initial data of all dedicated variables of the multi-processor, they have the same name but different storage locations." (Excerpt from Section 31.1)
Without a deep understanding of the technology and careful induction, you cannot complete this book. When you hold this book and carefully study it, you will surely get a better eye for the book to solve the problems one by one!
The book deeply analyzes the Linux kernel source code, allowing readers to understand the kernel principles and further guide future development, this effectively promotes the combination and mutual improvement of theories and practices, and ultimately achieves the realm of "no matter how the wind blows, it is better than nothing else!