Book Image

Mastering Embedded Linux Programming

By : Chris Simmonds
Book Image

Mastering Embedded Linux Programming

By: Chris Simmonds

Overview of this book

Mastering Embedded Linux Programming takes you through the product cycle and gives you an in-depth description of the components and options that are available at each stage. You will begin by learning about toolchains, bootloaders, the Linux kernel, and how to configure a root filesystem to create a basic working device. You will then learn how to use the two most commonly used build systems, Buildroot and Yocto, to speed up and simplify the development process. Building on this solid base, the next section considers how to make best use of raw NAND/NOR flash memory and managed flash eMMC chips, including mechanisms for increasing the lifetime of the devices and to perform reliable in-field updates. Next, you need to consider what techniques are best suited to writing applications for your device. We will then see how functions are split between processes and the usage of POSIX threads, which have a big impact on the responsiveness and performance of the final device The closing sections look at the techniques available to developers for profiling and tracing applications and kernel code using perf and ftrace.
Table of Contents (22 chapters)
Mastering Embedded Linux Programming
About the Author
About the Reviewers


A process holds the environment in which threads can run: it holds the memory mappings, the file descriptors, the user and group IDs, and more. The first process is the init process, which is created by the kernel during boot and has a PID of one. Thereafter, processes are created by duplication in an operation known as forking.

Creating a new process

The POSIX function to create a process is fork(2). It is an odd function because, for each successful call, there are two returns: one in the process that made the call, known as the parent, and one in the newly created process, known as the child as shown in the following diagram:

Immediately after the call, the child is an exact copy of the parent, it has the same stack, the same heap, the same file descriptors, and executes the same line of code, the one following fork(2). The only way the programmer can tell them apart is by looking at the return value of fork: it is zero for the child and greater than zero for the parent. Actually...