| This chapter deals with the basic architecture of the Linux kernel and its components. It provides an overview of the most important areas of the kernel, such as the different forms of activity in the kernel, memory management, device drivers, timers, and modules. Each of these issues will be discussed briefly in this book, to give you an insight into the tasks and processes of each component. Detailed information about each of these issues is found in other books and references. A choice of corresponding sources is given in the bibliography, where we particularly recommend [RuCo01], [BBDK+01], and [BoCe00]. The goal of this chapter is to describe the framework in which the Linux network architecture operates. All areas described below offer basic functions required to offer network services in the first place. This is the reason why knowing them is an essential prerequisite for an understanding of the implementation of the Linux networking architecture. Figure 2-1 shows the structure of the Linux kernel. The kernel can be divided into six different sections, each possessing a clearly defined functionality and offering this functionality to the other kernel components. This organization is reflected also in the kernel's source code, where each of these sections is structured in its own subtree. Figure 2-1. Structure of the Linux kernel according to [RuCo01]. 
Here we briefly describe these components. Process management: This area is responsible for creating and terminating processes and other activities of the kernel (software interrupts, tasklets, etc.). In addition, this is the area where interprocess communication (signals, pipes, etc.) takes place. The scheduler is the main component of process management. It handles all active, waiting, and blocked processes and takes care that all application processes obtain their fair share of the processor's computing time. Memory management: The memory of a computer is one of the most important resources. A computer's performance strongly depends on the main memory it is equipped with. In addition, memory management is responsible for allowing each process its own memory section, which has to be protected against access by other processes. File systems: In UNIX, the file system assumes a central role. In contrast to other operating systems (e.g., Windows NT), almost everything is handled over the file-system interface. For example, device drivers can be addressed as files, and the Proc file system (see Section 2.8) allows you to access data and parameters within the kernel. These two functionalities can be used very effectively and elegantly, so that they are often used for debugging purposes. (See Appendix B.) Device drivers: Device drivers abstract from the underlying hardware in every operating system, and they allow you to access this hardware. The modular concept of Linux we will introduce in Section 2.4 offers a way to add or remove device drivers during a running operation, despite its monolithic kernel. Network: All network operations have to be managed by the operating system, because certain network operations cannot be allocated to a specific process, such as handling an incoming packet. Incoming packets are asynchronous events. They have to be collected, identified, and forwarded before a process can handle them. This is the reason why the kernel is responsible for the handling of packets across program and network interfaces.
Within the kernel, defined interfaces are used to facilitate the design of new functionalities. For instance, there is an interface to the virtual file system, which can be used to add new file systems. The availability of more than a dozen supported file systems shows clearly that this interface was a good design decision by the Linux developers, because no other operating system provides such a large supply of supported file systems. The Linux network architecture also includes many interfaces supporting the dynamic enhancement of the wealth of protocols and network drivers. The components shown on dark background in Figure 2-1 provide interfaces for the dynamic registration of new functionalities, so that such functionalities can be easily implemented in modules. |
