Hello everyone, I am Bug Jun~
In most people’s impression, writing a technical book is just about organizing what you know. However, when the subject is the Linux kernel, it becomes like performing ballet on a tightrope — one of the most complex open-source software in the world, a giant system composed of 28 million lines of code, involving dozens of precisely operating sub-modules such as process scheduling, memory management, and file systems, where each technical point may lead to over a decade of version iteration history.
I once saw the writing notes of a senior kernel developer: to clarify the evolution of the CFS scheduling algorithm, he hand-drew seven versions of state transition diagrams, comparing 23 key code modifications over 14 years from version 2.6.23 to 5.15; when explaining memory barriers, he not only had to thoroughly understand the hardware semantics of x86, ARM, and PowerPC architectures but also trace back to the classic paper published by Paul E. McKenney in 2001. This kind of writing is essentially an archaeology of technical history, as well as a re-encoding of the knowledge system.
What’s more challenging is maintaining the timeliness of the technology. The Linux kernel races ahead with two major version updates each year; a memory management chapter that was just completed last year may need to be completely rewritten this year due to the restructuring of the transparent huge pages mechanism. A senior developer once revealed in the postscript: to wait for the BPF JIT compiler feature to freeze in version 5.10, he postponed the submission date by 173 days, during which he had to synchronize the changes in the mainline code every week.
The daily life of these authors is about finding balance under triple pressure: during the day, they are the technical backbone of internet companies, dealing with product iterations, cross-department collaboration, and online failures; at night, they face kernel code that needs line-by-line debugging and manuscripts waiting for polishing.
At a technical salon, I once asked several friends who write technical books: “Writing such books is time-consuming and labor-intensive, why not go directly into consulting to make quick money?” He pointed to the Linux kernel architecture diagram on the PPT and said: “Does this look like a great cathedral? Each module is an arch built by countless developers with code, and my job is to hand a ladder to those who come after.” This kind of craftsman-like dedication is reflected in the extreme pursuit of details.
Recently, I came across a new book titled “Connecting Linux Operating System and Chip Development,” so I flipped through it to see its unique insights on learning Linux systems:
The main content of this book
The content follows a progressive logic from basic operating system theory to embedded system practice, with a core focus on software-hardware collaboration, constructing a complete knowledge system:
Foundation Layer — Core Mechanisms of the Operating SystemFirst, it revolves around the basic resource management of computer systems: memory management from physical memory initialization (memblock mechanism) to dynamic allocation strategies (buddy system, water level control, fragmentation), constructing the physical space for process execution; process management analyzes task execution units (process/thread creation, scheduling algorithms, multi-core load balancing), forming a concurrent execution framework; the file system connects storage media (disk structure) with application layer data access (VFS abstraction), achieving persistent data management; synchronization mechanisms (atomic operations, spin locks, RCU) and system calls (user/kernel mode switching mechanisms) ensure the safe and reliable competition for resources and system service calls. These five modules constitute the “skeleton” and “nerves” of the operating system, coordinating core resources such as CPU, memory, and storage.
Boot Layer — Initialization Process of Embedded SystemsFocusing on the complete link from SoC cold boot to operating system running: after powering on the hardware, the minimal firmware (SPL) initializes key peripherals, booting the trusted execution environment (ATF); the Bootloader (like Uboot) completes memory mapping, device tree loading, and transfers control to the kernel; the Linux kernel initializes subsystems (memory, processes, interrupts, etc.) hierarchically, establishing a basic operating environment. This process reveals how hardware transitions from a bare-metal state to an operating system capable of executing complex tasks through multi-level software relays.
Abstraction Layer — Device and Driver ModelTo connect hardware and the operating system, the device model constructs a bus-device-driver topology through abstract entities like sysfs and kobject, achieving dynamic discovery and management of hardware resources; the device tree (DT) describes hardware configurations in a declarative syntax (.dts/.dtb), decoupling hardware differences from driver code. Together, they form the Hardware Abstraction Layer (HAL), providing standardized interfaces for driver development, allowing the operating system to adapt to diverse hardware platforms.
Hardware Collaboration Layer — Deep Integration of Key SoC ModulesIn-depth design of software-hardware collaboration for various functional modules of SoC:
- Power Management: Achieved through Power Domain division and Runtime PM dynamic regulation, realizing refined power consumption management (like sleep-wake mechanisms);
- Clock System: Clock tree configuration and Common Clock Framework (CCF) drivers ensure timing synchronization for CPU and peripherals;
- Pin Control: IOMUX controllers achieve pin function multiplexing (GPIO, UART, etc.), expanding peripheral connection capabilities;
- Time Module: High-precision timers (hrtimer) and scheduling clocks (sched_timer) support task scheduling and real-time performance;
- Interrupt System: Interrupt controller (like GIC) drivers and bottom-half processing (soft interrupts, tasklets) coordinate asynchronous event responses. Each module extends from hardware principles (register operations, circuit design) to Linux driver implementations (clock subsystems, GPIO subsystems, etc.), reflecting the complete path of hardware functions exposed to the operating system through software interfaces.
Logical Evolution Path
- Horizontal Layering: Expanding from general computing theory (memory/process/file) to embedded customization (boot process, device tree), establishing cognition across platforms and dedicated scenarios;
- Vertical Integration: For each hardware module (like interrupts), analyzing the vertical integration of hardware behavior, kernel subsystems, and driver APIs, reinforcing the full-link thinking of “signal trigger → driver processing → application response”;
- Dynamic Interaction: Emphasizing inter-module interaction, for example, power management relies on timers and interrupts to achieve low-power state switching, and the clock system provides a time reference for process scheduling, reflecting system-level collaboration.
This framework is suitable for embedded developers to delve into the adaptation details of the Linux kernel and SoC, and also provides system engineers with a panoramic view of “hardware boot → driver abstraction → service exposure,” ultimately achieving a seamless transition from theory to product development, which is great~
Finally
That’s all for today. If you found this helpful, be sure to give alike~
Unique, permanent, and free sharing platform for embedded technology knowledge~
Recommended Albums Click the blue text to jump
☞ MCU Advanced Album
☞ Embedded C Language Advanced Album
☞ “Bug Says” Album
☞ Album | Comprehensive Programming of Linux Applications
☞ Album | Learn Some Networking Knowledge
☞ Album | Handwritten C Language
☞ Album | Handwritten C++ Language
☞ Album | Experience Sharing
☞ Album | Power Control Technology
☞ Album | From Microcontroller to Linux
