Linux设备驱动开发：第3版详解

需积分: 3 129 浏览量更新于2024-08-02 收藏 12.25MB PDF 举报

"Linux设备驱动第3版是一本经典的IT教材，专注于讲解Linux 2.6内核的设备驱动开发。本书旨在帮助读者理解和掌握如何构建和管理Linux系统中的设备驱动程序，以支持硬件功能的充分利用。" 在书中，作者首先介绍了设备驱动的基本概念和它们在操作系统中的角色。设备驱动是操作系统与硬件设备之间的桥梁，负责处理硬件操作并提供高级接口给应用程序。书中提到了Linux内核的分层结构，解释了为何将驱动程序设计为可加载模块，以便于系统的动态扩展和维护。接着，书中讨论了不同类型的设备（如字符设备、块设备等）以及模块，这些都是驱动程序的核心类别。安全问题也是重点之一，因为设备驱动可以直接访问硬件，所以必须谨慎处理权限和访问控制，以防止恶意利用。版本编号和许可条款的讨论有助于读者理解驱动程序的兼容性和开源社区的规则。在构建和运行模块的章节中，作者引导读者设置测试环境，并通过“Hello World”模块实例来实践编译和加载过程。这一部分详细解释了内核符号表、初始化和关闭流程，以及模块参数的使用。此外，还探讨了在用户空间操作设备驱动的可能性，这为不直接修改内核提供了便利。接下来，深入到字符驱动的实现，以scull设备为例。scull是一种模拟设备，用于教学目的，它展示了如何分配和管理设备的主/次设备号，以及关键数据结构的使用。书中详细阐述了open、release、read和write等基本操作的实现，并指导读者如何与新设备进行交互。在调试技术章节，作者介绍了内核级别的调试方法，包括打印信息、查询状态、监控变化以及处理系统故障。此外，还讨论了各种调试工具的使用，如GDB等，这对于解决驱动程序中的问题至关重要。 "Linux设备驱动第3版"不仅涵盖了设备驱动的基础知识，还包括实际操作和调试技巧，是学习Linux内核驱动开发的宝贵资源。通过对这本书的学习，读者可以掌握开发高效、安全的设备驱动程序所需的技术和最佳实践，从而更好地适应和优化Linux系统。

This is the Title of the Book, eMatter Edition

xviii

Preface

have been gratifying and inspiring. And I would especially like to thank Alessandro

Rubini for starting this whole exercise with the first edition (and staying with it

through the current edition); and Greg Kroah-Hartman, who has brought his consid-

erable skills to bear on several chapters, with great results.

Alessandro

I would like to thank the people that made this work possible. First of all, the incred-

ible patience of Federica, who went as far as letting me review the first edition dur-

ing our honeymoon, with a laptop in the tent. I want to thank Giorgio and Giulia,

who have been involved in later editions of the book and happily accepted to be sons

of “a gnu” who often works late in the night. I owe a lot to all the free-software

authors who actually taught me how to program by making their work available for

anyone to study. But for this edition, I’m mostly grateful to Jon and Greg, who have

been great mates in this work; it couldn’t have existed without each and both of

them, as the code base is bigger and tougher, while my time is a scarcer resource,

always contended for by clients, free software issues, and expired deadlines. Jon has

been a great leader for this edition; both have been very productive and technically

invaluable in supplementing my small-scale and embedded view toward program-

ming with their expertise about SMP and number crunchers.

Greg

I would like to thank my wife Shannon and my children Madeline and Griffin for

their understanding and patience while I took the time to work on this book. If it

were not for their support of my original Linux development efforts, I would not be

able to do this book at all. Thanks also to Alessandro and Jon for offering to let me

work on this book; I am honored that they let me participate in it. Much gratitude is

given to all of the Linux kernel programmers, who were unselfish enough to write

code in the public view, so that I and others could learn so much from just reading it.

Also, for everyone who has ever sent me bug reports, critiqued my code, and flamed

me for doing stupid things, you have all taught me so much about how to be a better

programmer and, throughout it all, made me feel very welcome to be part of this

community. Thank you.

,ch00.11770 Page xviii Thursday, January 27, 2005 12:11 PM

This is the Title of the Book, eMatter Edition

Chapter 1

CHAPTER 1

An Introduction to

Device Drivers

One of the many advantages of free operating systems, as typified by Linux, is that

their internals are open for all to view. The operating system, once a dark and myste-

rious area whose code was restricted to a small number of programmers, can now be

readily examined, understood, and modified by anybody with the requisite skills.

Linux has helped to democratize operating systems. The Linux kernel remains a

large and complex body of code, however, and would-be kernel hackers need an

entry point where they can approach the code without being overwhelmed by com-

plexity. Often, device drivers provide that gateway.

Device drivers take on a special role in the Linux kernel. They are distinct “black

boxes” that make a particular piece of hardware respond to a well-defined internal

programming interface; they hide completely the details of how the device works.

User activities are performed by means of a set of standardized calls that are indepen-

dent of the specific driver; mapping those calls to device-specific operations that act

on real hardware is then the role of the device driver. This programming interface is

such that drivers can be built separately from the rest of the kernel and “plugged in”

at runtime when needed. This modularity makes Linux drivers easy to write, to the

point that there are now hundreds of them available.

There are a number of reasons to be interested in the writing of Linux device drivers.

The rate at which new hardware becomes available (and obsolete!) alone guarantees

that driver writers will be busy for the foreseeable future. Individuals may need to

know about drivers in order to gain access to a particular device that is of interest to

them. Hardware vendors, by making a Linux driver available for their products, can

add the large and growing Linux user base to their potential markets. And the open

source nature of the Linux system means that if the driver writer wishes, the source

to a driver can be quickly disseminated to millions of users.

This book teaches you how to write your own drivers and how to hack around in

related parts of the kernel. We have taken a device-independent approach; the pro-

gramming techniques and interfaces are presented, whenever possible, without being

tied to any specific device. Each driver is different; as a driver writer, you need to

,ch01.2168 Page 1 Thursday, January 20, 2005 9:21 AM

This is the Title of the Book, eMatter Edition

Chapter 1: An Introduction to Device Drivers

understand your specific device well. But most of the principles and basic tech-

niques are the same for all drivers. This book cannot teach you about your device,

but it gives you a handle on the background you need to make your device work.

As you learn to write drivers, you 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 introduce new

ideas gradually, starting off with very simple drivers and building on them; every new

concept is accompanied by sample code that doesn’t need special hardware to be

tested.

This chapter doesn’t actually get into writing code. However, we introduce some

background concepts about the Linux kernel that you’ll be glad you know later,

when we do launch into programming.

The Role of the Device Driver

As a programmer, you are able to make your own choices about your driver, and

choose an acceptable trade-off between the programming time required and the flexi-

bility of the result. Though it may appear strange to say that a driver is “flexible,” we

like this word because it emphasizes that the role of a device driver is providing

mechanism, not policy.

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

capabilities are to be provided” (the mechanism) and “how those capabilities can 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 and session managers, which implement a particular policy without know-

ing anything about the hardware. People can use the same window manager on dif-

ferent hardware, and different users can run different configurations on the same

workstation. Even completely different desktop environments, such as KDE and

GNOME, can coexist on the same system. Another example is the layered structure

of TCP/IP networking: the operating system offers the socket abstraction, which

implements no policy regarding the data to be transferred, while different servers are

in charge of the services (and their associated policies). 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 inter-

face to transfer files.

Where drivers are concerned, the same separation of mechanism and policy applies.

The floppy driver is policy free—its role is only to show the diskette as a continuous

,ch01.2168 Page 2 Thursday, January 20, 2005 9:21 AM

This is the Title of the Book, eMatter Edition

The Role of the Device Driver

array of data blocks. Higher levels of the system provide policies, such as who may

access the floppy drive, whether the drive is accessed directly or via a filesystem, and

whether users may mount filesystems on the drive. Since different environments usu-

ally need to use hardware in different ways, it’s important to be as policy free as

possible.

When writing drivers, a programmer should pay particular attention to this funda-

mental concept: write kernel code to access the hardware, but don’t force particular

policies on the user, since different users have different needs. The driver should deal

with making the hardware available, leaving all the issues about how to use the hard-

ware 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. For example, a digital I/O driver may only offer byte-wide access to

the hardware in order to avoid the extra code needed to handle individual bits.

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 trade-off between the desire to present the user with as many

options as possible and the time you have to write the driver, as well as the need to

keep things simple so that errors don’t creep in.

Policy-free drivers have a number of typical characteristics. These include support for

both synchronous and asynchronous operation, the ability to be opened multiple

times, the ability to exploit the full capabilities of the hardware, and the lack of soft-

ware layers to “simplify things” or provide policy-related operations. Drivers of this

sort not only work better for their end users, but also turn out to be easier to write

and maintain as well. Being policy-free is actually a common target for software

designers.

Many 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

utilities to complete graphical applications. Examples include the tunelp program,

which adjusts how the parallel port printer driver operates, and the graphical cardctl

utility that is part of the PCMCIA driver package. Often a client library is provided as

well, which provides capabilities that do not need to be implemented as part of the

driver itself.

,ch01.2168 Page 3 Thursday, January 20, 2005 9:21 AM

This is the Title of the Book, eMatter Edition

Chapter 1: An Introduction to Device Drivers

The scope of this book is the kernel, so we try not to deal with policy issues or with

application programs or support libraries. Sometimes we talk about different poli-

cies and how to support them, but we 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 han-

dling all such requests. Although 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:

Process management

The kernel is in charge of creating and destroying processes and handling their

connection to the outside world (input and output). Communication among dif-

ferent processes (through signals, pipes, or interprocess communication primi-

tives) is basic to the overall system functionality and is also handled by the

kernel. In addition, the scheduler, which controls how processes share the CPU,

is part of process management. More generally, the kernel’s process manage-

ment activity implements the abstraction of several processes on top of a single

CPU or a few of them.

Memory management

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 address-

ing 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 the simple malloc/free pair to much

more complex functionalities.

Filesystems

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 unstruc-

tured hardware, and the resulting file abstraction is heavily used throughout the

whole system. In addition, Linux supports multiple filesystem types, that is, dif-

ferent ways of organizing data on the physical medium. For example, disks may

be formatted with the Linux-standard ext3 filesystem, the commonly used FAT

filesystem or several others.

,ch01.2168 Page 4 Thursday, January 20, 2005 9:21 AM

剩余631页未读，继续阅读

xunjun2006

粉丝: 2
资源: 19

Linux设备驱动开发：第3版详解

Linux设备驱动第3版(中文版)

Linux设备驱动第3版(英文版)

Linux 设备驱动第3版（中英文）

《Linux设备驱动第3版》英文原版高清附标签

linux设备驱动程序第3版

linux设备驱动程序 第3版

Linux驱动中文第3版

LINUX设备驱动程序第3版完整版.pdf

linux设备驱动程序（第3版）

LINUX设备驱动程序（第3版）

最新资源

linux设备驱动程序第3版