Getting Started with Linux Systems and the POSIX Standard

This book is about Linux and how we use C++ in Linux environments to manage critical resources. The C++ language is continuously improving, as you’ll explore in the following chapters. Before we go there, we’d like to spend some time in this chapter developing a fundamental understanding of operating systems (OSs). You are going to learn more about the origins of some specific techniques, the system call interface and the Portable Operating System Interface (POSIX).

Your choice of OS matters. Although OSs were created with a single purpose, nowadays their roles differ. Much is expected of them as well. Each OS has its own strengths and weaknesses, which we are going to discuss briefly. Linux is in widespread use across multiple technological areas and has a huge community worldwide, so it is perfect for our practical purposes. In our experience, programming in Linux or other Unix-based OS environments is rather...

Technical requirements

In order to get familiar with the programming environment, the reader must prepare the following:

• A Linux-based system capable of compiling and executing C++20 (for example, Linux Mint 21)

Getting familiar with the concept of OSs

So, what is an OS? You could probably provide at least one answer, but let’s discuss this briefly as it is important to understand what our computer system truly is and how we manipulate it. Although you might be familiar with most of the information provided here, we are using this chapter to align with you on the matter of OSs and their uses. Some might say that the OS was created to make the hardware work as a whole. Others will argue that it is an aggregation of programs, dedicated to managing the system resources overall. It is crucial to utilize these resources, such as CPU and memory, efficiently. There is also the concept of the OS as an abstraction and an extension of the hardware. Ultimately, we can safely say that the modern OS is a complex entity. It also has additional functions, such as the collection of statistics, multimedia handling, system safety and security, overall stability, reliable error handling, and so on.

...

Getting to know the Linux kernel

Figure 1.1 illustrates an example of a Linux kernel. Based on your needs, the system architecture could look different, but you can observe the three main layers we expect to see in any given Linux system.

These are the user space (running processes and their threads), the kernel space (the running kernel itself, usually a process of its own), and the computer – this could be any kind of computing device, such as a PC, tablet, smartphone, supercomputer, IoT device, and so on. One by one, all the terms observed in the diagram will fall into place as we explain them in the following chapters, so don’t worry if you are not familiar with all of them right now.

Figure 1.1 – Overview of the Linux kernel and the neighboring layers

Some interdependencies in the preceding diagram have probably made an impression on you already. For example, see how the device drivers, the respective devices, and the...

Introducing the system call interface and system programming

Of course, the example that we just saw is simplified but gives us some idea about the work that the OS needs to do – in essence, it is responsible for managing and providing resources, but at the same time remains available for other processes’ requests. This is a messy job on modern OSs. Rarely can we do anything about it. So, to have better control and predictability of system behavior, programmers might directly use the OS’s API, called the system call interface.

Important note

The NVM data request is a procedure that benefits from the system call interface, as the OS will be obliged to turn this request into an application binary interface (ABI) call, referring to the respective device driver. Such an operation is known as a system call. Using system calls to implement or execute functions provided by the OS is known as system programming. The system calls are the only entry points to the kernel...

Navigating through files, processes, and threads

If you made it to here – great job! We are going to cover processes and threads thoroughly in Chapter 2, and filesystems in Chapter 3. In the meantime, we will take a short detour here, just to paint a better picture for you, through the definition of three important terms: files, processes, and threads. You probably already noticed two of these in the kernel overview earlier, so we will explain them briefly now in case you are not familiar with them.

File

In short, we require files to represent multiple kinds of resources on our system. The programs we write are files as well. The compiled code, for example, the executable binaries (.bin, .exe), and the libraries are all files (.o, .so, .lib, .dll, and so on). Additionally, we need them for communication mechanisms and for storage management. Do you know what types of files are recognizable on Linux? Let’s brief you on that quickly:

• Ordinary or regular files...

Running services with init and systemd

Let’s use this opportunity to discuss the init and the systemd process daemons. There are others as well, but we’ve decided to retain our focus on these two. The first one is the initial process, executed on a Linux system by the kernel, and its pid is always 1:

$ ps -p 1
PID TTY          TIME CMD
1 ?        04:53:20 systemd

It is known as the parent of all processes on the system as it is used to initialize, manage, and track other services and daemons. The first init daemon for Linux is called Init and it defines six system states. All system services are mapped to those states, respectively. Its script is used to start processes in a pre-defined order, which is occasionally used by system programmers. One possible reason to use this is to reduce the startup duration of the system. To create a service or edit the script, you could modify...

Portable Operating System Interface (POSIX)

The POSIX standard has the main task of maintaining compatibility between different OSs. Therefore, POSIX is frequently used by both standard application software developers and system programmers. Nowadays, it can be found not only on Unix-like OSs, but in Windows environments as well – for example, Cygwin, MinGW, and Windows Subsystem for Linux (WSL). POSIX defines both the system- and the user-level APIs with one remark: using POSIX, the programmer doesn’t need to distinguish between system calls and library functions.

The POSIX API is frequently used in the C programming language. Thus, it is compilable with C++. Additional functions are provided to the system call interface in a few important areas of system programming: file operations, memory management, process and thread control, networking and communications, and regular expressions – as you can see, it pretty much covers everything that the already existing...

Summary

In this chapter, we have covered the definitions of basic concepts related to OSs. You have learned about Linux’s main kernel structure and its expectations of software design. Real-time OSs were briefly introduced, and we covered the definitions of system calls, the system call interface, and POSIX as well. We’ve also laid the foundations of multiprocessing and multithreading. In the next chapter, we will discuss the process as the main resource user and manager. We will start with some C++20 code. Through this, you will learn about the Linux’s process memory layout, the OS’s process-scheduling mechanism, and how multiprocessing operates plus the challenges it brings. You will also learn some interesting facts about atomic operations.