LDD3：Linux设备驱动英文版详解

需积分: 10 195 浏览量更新于2024-07-20 收藏 7.33MB PDF 举报

"LDD3 Linux设备驱动英文版" 《LDD3: Linux Device Drivers》是Linux设备驱动程序开发的经典著作，由O'Reilly出版社出版。这本书深入浅出地讲解了如何编写和理解Linux操作系统下的设备驱动程序。全书以英文形式呈现，适合具有一定Linux系统基础和C语言编程经验的读者。 LDD3 (Linux Device Drivers, Third Edition) 是对Linux内核与硬件交互机制的权威指南。书中涵盖了从简单的字符设备驱动到复杂的块设备驱动、网络设备驱动以及中断处理、I/O端口访问、DMA操作等多个方面。通过对具体例子的分析和讲解，读者可以了解到如何与硬件进行通信，如何注册和管理设备，以及如何利用内核提供的API来实现驱动程序的功能。书中的部分内容提及了Linux内核的工作原理，如中断处理机制、设备模型、内存管理和I/O子系统等。这些是编写任何设备驱动的基础，因为它们决定了设备如何与操作系统交互并有效地使用系统资源。此外，书中还讨论了异步通知（例如，使用中断处理程序）和同步操作（如轮询模式）的实现，这对于理解和优化驱动性能至关重要。对于网络设备驱动，LDD3讲解了如何处理网络数据包，以及如何实现协议栈与硬件之间的通信。这包括配置网络接口、发送和接收数据包，以及错误处理和统计功能。除了核心的设备驱动开发知识，LDD3还涉及到了嵌入式系统开发和硬件设计，这对于那些希望在嵌入式环境中工作或者设计自己的硬件平台的读者非常有价值。书中可能会讨论如何在资源受限的环境下优化驱动代码，以及如何针对特定硬件平台进行适配。 O'Reilly出版社还提供了其他与Linux相关的资源，如《Understanding the Linux Kernel》深入解析了Linux内核的工作机制，《Linux in a Nutshell》是一本实用的速查手册，《Running Linux》则提供了系统管理的实用技巧。此外，ONLamp.com网站是开源网络平台的权威资源，涵盖了Linux、Apache、MySQL和多种脚本语言的最新资讯和实践指导。 O'Reilly Conferences是业界专业人士交流创新思想的平台，经常举办关于Linux和相关技术的活动。Safari Bookshelf在线参考图书馆是程序员和IT专业人员的重要资源，订阅者可以访问超过1000本书的内容，进行搜索和学习，快速找到问题的答案。《LDD3: Linux Device Drivers》是深入理解Linux系统底层运作，特别是对于有志于开发设备驱动程序的开发者而言，是一本不可或缺的参考书籍。通过阅读和实践书中的内容，读者将能够掌握创建高效、可靠的Linux设备驱动的技能。

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

This is the Title of the Book, eMatter Edition

Classes of Devices and Modules

Block devices

Like char devices, block devices are accessed by filesystem nodes in the /dev

directory. A block device is a device (e.g., a disk) that can host a filesystem. In

most Unix systems, a block device can only handle I/O operations that transfer

one or more whole blocks, which are usually 512 bytes (or a larger power of

two) bytes in length. Linux, instead, allows the application to read and write a

block device like a char device—it permits the transfer of any number of bytes at

a time. As a result, block and char devices differ only in the way data is managed

internally by the kernel, and thus in the kernel/driver software interface. Like a

char device, each block device is accessed through a filesystem node, and the dif-

ference between them is transparent to the user. Block drivers have a completely

different interface to the kernel than char drivers.

Network interfaces

Any network transaction is made through an interface, that is, a device that is

able to exchange data with other hosts. Usually, an interface is a hardware

device, but it might also be a pure software device, like the loopback interface. A

network interface is in charge of sending and receiving data packets, driven by

the network subsystem of the kernel, without knowing how individual transac-

tions map to the actual packets being transmitted. Many network connections

(especially those using TCP) are stream-oriented, but network devices are, usu-

ally, designed around the transmission and receipt of packets. A network driver

knows nothing about individual connections; it only handles packets.

Not being a stream-oriented device, a network interface isn’t easily mapped to a

node in the filesystem, as /dev/tty1 is. The Unix way to provide access to inter-

faces is still by assigning a unique name to them (such as

eth0), but that name

doesn’t have a corresponding entry in the filesystem. Communication between

the kernel and a network device driver is completely different from that used

with char and block drivers. Instead of read and write, the kernel calls functions

related to packet transmission.

There are other ways of classifying driver modules that are orthogonal to the above

device types. In general, some types of drivers work with additional layers of kernel

support functions for a given type of device. For example, one can talk of universal

serial bus (USB) modules, serial modules, SCSI modules, and so on. Every USB

device is driven by a USB module that works with the USB subsystem, but the device

itself shows up in the system as a char device (a USB serial port, say), a block device

(a USB memory card reader), or a network device (a USB Ethernet interface).

Other classes of device drivers have been added to the kernel in recent times, includ-

ing FireWire drivers and I2O drivers. In the same way that they handled USB and

SCSI drivers, kernel developers collected class-wide features and exported them to

driver implementers to avoid duplicating work and bugs, thus simplifying and

strengthening the process of writing such drivers.

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

This is the Title of the Book, eMatter Edition

Chapter 1: An Introduction to Device Drivers

In addition to device drivers, other functionalities, both hardware and software, are

modularized in the kernel. One common example is filesystems. A filesystem type

determines how information is organized on a block device in order to represent a

tree of directories and files. Such an entity is not a device driver, in that there’s no

explicit device associated with the way the information is laid down; the filesystem

type is instead a software driver, because it maps the low-level data structures to

high-level data structures. It is the filesystem that determines how long a filename

can be and what information about each file is stored in a directory entry. The file-

system module must implement the lowest level of the system calls that access direc-

tories and files, by mapping filenames and paths (as well as other information, such

as access modes) to data structures stored in data blocks. Such an interface is com-

pletely independent of the actual data transfer to and from the disk (or other

medium), which is accomplished by a block device driver.

If you think of how strongly a Unix system depends on the underlying filesystem,

you’ll realize that such a software concept is vital to system operation. The ability to

decode filesystem information stays at the lowest level of the kernel hierarchy and is

of utmost importance; even if you write a block driver for your new CD-ROM, it is

useless if you are not able to run ls or cp on the data it hosts. Linux supports the con-

cept of a filesystem module, whose software interface declares the different opera-

tions that can be performed on a filesystem inode, directory, file, and superblock. It’s

quite unusual for a programmer to actually need to write a filesystem module,

because the official kernel already includes code for the most important filesystem

types.

Security Issues

Security is an increasingly important concern in modern times. We will discuss secu-

rity-related issues as they come up throughout the book. There are a few general con-

cepts, however, that are worth mentioning now.

Any security check in the system is enforced by kernel code. If the kernel has secu-

rity holes, then the system as a whole has holes. In the official kernel distribution,

only an authorized user can load modules; the system call init_module checks if the

invoking process is authorized to load a module into the kernel. Thus, when run-

ning an official kernel, only the superuser,

or an intruder who has succeeded in

becoming privileged, can exploit the power of privileged code.

When possible, driver writers should avoid encoding security policy in their code.

Security is a policy issue that is often best handled at higher levels within the kernel,

under the control of the system administrator. There are always exceptions, however.

* Technically, only somebody with the CAP_SYS_MODULE capability can perform this operation. We discuss

capabilities in Chapter 6.

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

剩余623页未读，继续阅读

dawnscofield

粉丝: 0
资源: 4

LDD3：Linux设备驱动英文版详解

ldd3英文原版书以及源码

Linux设备驱动 ldd3中文第三版

linux device drivers ldd3代码

linux驱动开发网址

linux驱动书籍pdf

linux设备驱动程序pdf

linux 驱动开发书籍

有linux驱动开发的资料吗

linux执行unity打包文件报错

linux 离线安装 libncurses.so.5

最新资源