Linux设备驱动开发：经典书籍分享

5星 · 超过95%的资源需积分: 10 67 浏览量更新于2024-08-02 收藏 10.39MB PDF 举报

"Linux Device Driver 3rd 是一本经典的Linux驱动程序开发书籍，适合所有对Linux内核和驱动编程感兴趣的读者。这本书详细介绍了如何编写和理解Linux设备驱动，是Linux技术爱好者和专业开发者的宝贵资料。O'Reilly出版社还提供了其他相关Linux资源，包括书籍、样本章节和代码示例，以及在线参考图书馆Safari Bookshelf，为读者提供全面的学习平台。" Linux设备驱动是操作系统与硬件之间的重要桥梁，它们负责在软件和硬件之间进行通信，使得操作系统能够充分利用硬件的功能。《Linux Device Drivers 3rd》这本书深入浅出地讲解了Linux驱动程序开发的核心概念和技术，是学习这一领域的必备参考。书中可能包含以下关键知识点： 1. **驱动程序基础知识**：介绍驱动程序的角色、分类和工作原理，如字符设备驱动、块设备驱动、网络设备驱动等。 2. **Linux内核机制**：涵盖内核模块、中断处理、进程管理、内存管理、I/O子系统等相关内核概念，这些都是编写驱动的基础。 3. **设备模型**：讲解Linux设备模型，包括总线、设备、驱动的组织方式，以及uclass、device树等现代设备注册方法。 4. **驱动程序开发实践**：通过实例演示如何编写简单的字符设备驱动、块设备驱动和网络设备驱动，涉及驱动程序的初始化、数据传输、中断处理等环节。 5. **设备文件和文件操作**：讲解如何使用file_operations结构体定义设备文件的操作，如read、write、open、close等方法。 6. **DMA（直接内存访问）**：介绍如何利用DMA技术提高数据传输效率，降低CPU负担。 7. **中断处理**：详述中断处理过程，包括中断请求、中断服务例程、中断上下文等。 8. **PCI和USB设备驱动**：讲解PCI和USB设备的驱动开发，包括设备探测、配置、初始化等步骤。 9. **设备调试**：提供内核日志、sysfs、procfs等调试手段，帮助开发者定位问题。 10. **内核接口和API**：介绍Linux内核提供的驱动开发接口，如ioremap、kmalloc、spinlock、mutex等。通过阅读《Linux Device Drivers 3rd》，读者不仅可以掌握Linux驱动开发的基本技能，还能了解Linux内核的运行机制，从而更好地设计和优化驱动程序。同时，结合O'Reilly出版社提供的其他Linux资源，可以更全面地提升Linux技术能力。对于希望在嵌入式系统、服务器维护或物联网领域工作的IT专业人士来说，这本书是一份不可多得的参考资料。

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

This is the Title of the Book, eMatter Edition

Classes of Devices and Modules

Device control

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 all

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 a system, from the

hard drive to the keyboard and the tape drive. This aspect of the kernel’s func-

tions is our primary interest in this book.

Networking

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

cess takes care of them. The system is in charge of delivering data packets across

program and network interfaces, and it must control the execution of programs

according to their network activity. Additionally, all the routing and address res-

olution issues are implemented within the kernel.

Loadable Modules

One of the good features of Linux is the ability to extend at runtime the set of fea-

tures offered by the kernel. This means that you can add functionality to the kernel

(and remove functionality as well) while the system is up and running.

Each piece of code that can be added to the kernel at runtime 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 into a complete executable) that can be dynamically linked to the run-

ning kernel by the insmod program and can be unlinked by the rmmod program.

Figure 1-1 identifies different classes of modules in charge of specific tasks—a mod-

ule is said to belong to a specific class according to the functionality it offers. The

placement of modules in Figure 1-1 covers the most important classes, but is far from

complete because more and more functionality in Linux is being modularized.

Classes of Devices and Modules

The Linux way of looking at devices distinguishes between three fundamental device

types. Each module usually implements one of these types, and thus is classifiable as a

char module,ablock module,oranetwork module. This division of modules into dif-

ferent types, or classes, is not a rigid one; the programmer can choose to build huge

modules implementing different drivers in a single chunk of code. Good program-

mers, nonetheless, usually create a different module for each new functionality they

implement, because decomposition is a key element of scalability and extendability.

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

剩余509页未读，继续阅读

cangtyx

粉丝: 1
资源: 4

Linux设备驱动开发：经典书籍分享

Linux device driver linux 设备驱动开发_英文_原版 第三版

linux device drivers 中文版

linux device driver(linux设备驱动开发）

Linux Device Driver 3rd pdf

Linux Device Driver 3rd Edition.pdf

linux device driver 3rd

Linux Device Driver 3rd Edtion

linux device drivers 3rd.pdf

Linux Device Drivers 3rd Edition.pdf_LinuxDeviceDrivers_

Linux DeviceDrivers 3rd Edition

最新资源

Linux device driver linux 设备驱动开发_英文_原版第三版