Chapter One: An Introduction to the Linux Kernel
People all around the world are delving into the Linux kernel, mostly to write device drivers. While each driver is different, and you have to know your specific device, many principles and basic techniques are the same om one driver to another. In this book, you'll learn to write your own device drivers and to hack around in related parts of the kernel. This book covers device-independent programming techniques, without binding the examples to any specific device.
This chapter doesn't actually get into writing code. However, I'm going to introduce some background concepts about the Linux kernel that you'll be glad you know later, when we do launch into writing code.
As you learn to write drivers, you will find out a lot about the Linux kernel in general; this may help you understand how your machine works and why things aren't always as fast as you expect or don't do quite what you want. We'll introduce new ideas smoothly, starting off with very simple drivers and building upon them; every new concept will be accompanied by sample code that doesn't need special hardware to be tested.
The Role of the Driver Writer
As a programmer, you will be able to make your own choices about your driver, choosing an acceptable tradeoff between the programming time required and the flexibility of the result. Though it may appear strange to say that a driver is "flexible," I like this word because it emphasizes that the role of a device driver is providing mechanisms
, not policies
The distinction between mechanism and policy is one of the best ideas behind the Unix design. Most programming problems can indeed be split into two parts: "what needs to be done" (the mechanism) and "how can the program be used" (the policy). If the two issues are addressed by different parts of the program, or even by different programs altogether, the software package is much easier to develop and to adapt to particular needs.
For example, Unix management of the graphic display is split between the X server, which knows the hardware and offers a unified interface to user programs, and the window manager, which implements a particular policy without knowing anything about the hardware. People can use the same window manager on different hardware, and different users can run different configurations on the same workstation. Another example is the layered structure of TCP/IP networking: the operating system offers the socket abstraction, which is policy-free, while different servers are in charge of the services. Moreover, a server like ftpd provides the file transfer mechanism, while users can use whatever client they prefer; both command-line and graphic clients exist, and anyone can write a new user interface to transfer files.
Where drivers are concerned, the same role-splitting applies. The floppy driver is policy-free -- its role is only to show the diskette as a continuous byte array. How to use the device is the role of the application: tar writes it sequentially, while mkfs prepares the device to be mounted, and mcopy relies on the existence of a specific data structure on the device.
When writing drivers, a programmer should pay particular attention to this fundamental problem: we need to write kernel code to access the hardware, but we shouldn't force particular policies on the user, since different users have different needs. The driver should only deal with hardware handling, leaving all the issues about how to use the hardware to the applications. A driver, then, is "flexible" if it offers access to the hardware capabilities without adding constraints. Sometimes, however, some policy decisions must be made.
You can also look at your driver from a different perspective: it is a software layer that lies between the applications and the actual device. This privileged role of the driver allows the driver programmer to choose exactly how the device should appear: different drivers can offer different capabilities, even for the same device. The actual driver design should be a balance between many different considerations. For instance, a single device may be used concurrently by different programs, and the driver programmer has complete freedom to determine how to handle concurrency. You could implement memory mapping on the device independently of its hardware capabilities, or you could provide a user library to help application programmers implement new policies on top of the available primitives, and so forth. One major consideration is the tradeoff between the desire to present the user with as many options as possible, balanced against the time you have to do the writing and the need to keep things simple so that errors don't creep in.
If a driver is designed for both synchronous and asynchronous operations, if it allows itself to be opened multiple times, and if it is able to exploit all the hardware capabilities without adding a software layer "to simplify things" -- like converting binary data to text or other policy-related operations -- then it will turn out to be easier to write and to maintain. Being "policy-free" is actually a common target for software designers.
Most device drivers, indeed, are released together with user programs to help with configuration and access to the target device. Those programs can range from simple configuring utilities to complete graphical applications. Usually a client library is provided as well.
The scope of this book is the kernel, so we'll try not to deal with policy issues, nor with application programs or support libraries. Sometimes I'll talk about different policies and how to support them, but I won't go into much detail about programs using the device or the policies they enforce. You should understand, however, that user programs are an integral part of a software package and that even policy-free packages are distributed with configuration files that apply a default behavior to the underlying mechanisms.
Splitting the Kernel
In a Unix system, several concurrent processes
attend to different tasks. Each process asks for system resources, be it computing power, memory, network connectivity, or some other resource. The kernel is the big chunk of executable code in charge of handling all such requests. Though the distinction between the different kernel tasks isn't always clearly marked, the kernel's role can be split, as shown in Figure 1-1, into the following parts:
The kernel is in charge of creating and destroying processes, and handling their connection to the outside world (input and output). Communication among different processes (through signals, pipes, or interprocess communication primitives) is basic to the overall system functionality, and is also handled by the kernel. In addition, the scheduler, probably the most critical routine in the whole operating system, is part of process management. More generally, the kernel's process management activity implements the abstraction of several processes on top of a single CPU.
The computer's memory is a major resource, and the policy used to deal with it is a critical one for system performance. The kernel builds up a virtual addressing space for any and all processes on top of the limited available resources. The different parts of the kernel interact with the memory-management subsystem through a set of function calls, ranging from simple malloc/free equivalents to much more exotic functionalities.
Unix is heavily based on the filesystem concept; almost everything in Unix can be treated as a file. The kernel builds a structured filesystem on top of unstructured hardware, and the resulting file abstraction is heavily used throughout the whole system. In addition, Linux supports multiple filesystem types, i.e., different ways of organizing data on the physical medium.
Almost every system operation eventually maps to a physical device. With the exception of the processor, memory, and a very few other entities, any and a I device control operations are performed by code that is specific to the device being addressed. That code is called a device driver. The kernel must have embedded in it a device driver for every peripheral present on your system, from the hard drive to the keyboard and the tape streamer. This aspect of the kernel's functions is our primary interest in this book.
Networking must be managed by the operating system because most network operations are not specific to a process: incoming packets are asynchronous events. The packets must be collected, identified, and dispatched before a process takes care of them. The system is in charge of delivering data packets across program and network interfaces, and it must correctly put to sleep and wake programs waiting for data from the network. Additionally, all the routing and address resolution issues are implemented within the kernel.
Towards the end of this book, in Chapter 16, Physical Layout of the Kernel Source, you'll find a roadmap to the Linux kernel, but these few words should suffice for now.
One of the good features of Linux is the ability to expand the kernel code at run time. This means that you can add functionality to the kernel while the system is up and running.
Each piece of code that can be added to the kernel is called a module. The Linux kernel offers support for quite a few different types (or "classes") of modules, including, but not limited to, device drivers. Each module is made up of object code (not linked to be a complete executable) that can be dynamically linked to the running kernel by the insmod program and can be unlinked by the rmmod program.
In Figure 1-1, you can identify different classes of modules in charge of specific tasks -- a module is said to belong to a specific class according to the functionality it offers. ...