Book Image

Linux Kernel Programming - Second Edition

By : Kaiwan N. Billimoria
Book Image

Linux Kernel Programming - Second Edition

By: Kaiwan N. Billimoria

Overview of this book

The 2nd Edition of Linux Kernel Programming is an updated, comprehensive guide for new programmers to the Linux kernel. This book uses the recent 6.1 Long-Term Support (LTS) Linux kernel series, which will be maintained until Dec 2026, and also delves into its many new features. Further, the Civil Infrastructure Project has pledged to maintain and support this 6.1 Super LTS (SLTS) kernel right until August 2033, keeping this book valid for years to come! You’ll begin this exciting journey by learning how to build the kernel from source. In a step by step manner, you will then learn how to write your first kernel module by leveraging the kernel’s powerful Loadable Kernel Module (LKM) framework. With this foundation, you will delve into key kernel internals topics including Linux kernel architecture, memory management, and CPU (task) scheduling. You’ll finish with understanding the deep issues of concurrency, and gain insight into how they can be addressed with various synchronization/locking technologies (e.g., mutexes, spinlocks, atomic/refcount operators, rw-spinlocks and even lock-free technologies such as per-CPU and RCU). By the end of this book, you’ll have a much better understanding of the fundamentals of writing the Linux kernel and kernel module code that can straight away be used in real-world projects and products.
Table of Contents (16 chapters)
14
Other Books You May Enjoy
15
Index

Introducing memory barriers

Finally, let’s address another concern – that of the memory barrier. What does it mean? Sometimes, a program’s flow becomes unknown to the human programmer, as the microprocessor, the memory controllers, and the compiler can reorder memory reads and writes. In most cases, these “tricks” remain benign and typically optimize performance. But there are cases where this kind of reordering of (memory I/O) instruction sequences should not occur; the original and programmer-intended memory load and store sequences must be honored. What cases? Typically, these:

  • When working across hardware boundaries, such as across individual CPU cores on multicore systems
  • When performing atomic operations
  • When accessing peripheral devices (like performing I/O from a CPU to a peripheral device or vice versa, often via Direct Memory Access (DMA))
  • When working with hardware interrupts

The memory barrier (typically...