探索Linux内核：设备驱动程序开发(第2版)

需积分: 1 198 浏览量更新于2024-07-31 收藏 7.09MB PDF 举报

"LinuxDeviceDriver(2ndEdition)" 是一本关于编写Linux系统设备驱动程序的书籍，旨在让更多的开发者能够理解和适应Linux内核的工作原理，从而为各种新硬件产品编写驱动程序，使它们与Linux系统兼容。在内容部分，作者提到自第一版以来，Linux已经发生了许多变化。它现在可以在多种处理器上运行，支持更加广泛的硬件类型，而且内部编程接口也有了显著的变化。因此，第二版的书籍聚焦于2.4内核，不仅介绍了它的新特性，还兼顾了对早期版本的支持，以满足那些需要维护旧系统的人的需求。本书的核心内容将涵盖以下几个关键知识点： 1. Linux内核基础：了解Linux内核如何管理和协调硬件资源，包括内存管理、进程调度、中断处理和I/O操作等基本概念。 2. 设备驱动模型：深入学习Linux设备驱动模型，如字符设备、块设备和网络设备等，并掌握其注册、初始化、操作和卸载过程。 3. 硬件接口交互：探索如何与不同类型的硬件进行通信，如通过总线（如PCI、USB）或特定的硬件接口（如GPIO、SPI）来控制和读取数据。 4. 中断处理：理解中断处理机制，包括中断请求（IRQ）、中断服务例程（ISR）以及中断上下文的概念。 5. DMA（直接内存访问）：学习如何利用DMA技术提高数据传输效率，减少CPU负担。 6. 内核模块：探讨如何编写可动态加载和卸载的内核模块，以便灵活地添加或删除驱动程序。 7. 设备文件系统（sysfs、devfs、udev）：理解这些设备文件系统是如何帮助用户空间程序与内核驱动交互的。 8. 调试技巧：掌握内核日志、gdb、kdb等工具，用于调试驱动程序中的错误和问题。 9. 最新内核特性：介绍2.4内核的新特性，如电源管理、热插拔支持等，以及它们如何影响驱动开发。 10. 兼容性与向后兼容：讨论如何确保驱动程序同时兼容新旧内核版本，以及在不同版本间进行适配的策略。本书不仅适合于初次接触Linux驱动开发的读者，也为有经验的开发者提供了深入理解内核工作机制的机会。作者希望这本书能帮助更多的人进入Linux驱动开发领域，进一步扩大Linux系统的开发者社区。通过阅读本书，读者不仅可以学习到编写高效、可靠的设备驱动的技巧，还能了解到Linux系统设计背后的哲学和原则，从而成为更出色的Linux系统工程师。

text console (/dev/console) and the serial ports (/dev/ttyS0 and friends) are

examples of char devices, as they are well repr esented by the stream abstrac-

tion. Char devices are accessed by means of ﬁlesystem nodes, such as

/dev/tty1 and /dev/lp0. The only relevant differ ence between a char device and

a regular ﬁle is that you can always move back and forth in the regular ﬁle,

wher eas most char devices are just data channels, which you can only access

sequentially. There exist, nonetheless, char devices that look like data areas,

and you can move back and forth in them; for instance, this usually applies to

frame grabbers, where the applications can access the whole acquired image

using mmap or lseek.

Block devices

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

dir ectory. A block device is something that can host a ﬁlesystem, such as a

disk. In most Unix systems, a block device can be accessed only as multiples

of a block, where a block is usually one kilobyte of data or another power of

2. Linux allows the application to read and write a block device like a char

device — it per mits 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 inter face. Like a char device,

each block device is accessed through a ﬁlesystem node and the differ ence

between them is transparent to the user. A block driver offers the kernel the

same interface as a char driver, as well as an additional block-oriented inter-

face that is invisible to the user or applications opening the /dev entry points.

That block interface, though, is essential to be able to mount a ﬁlesystem.

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 softwar e device, like the loopback inter-

face. A network interface is in charge of sending and receiving data packets,

driven by the network subsystem of the kernel, without knowing how individ-

ual transactions map to the actual packets being transmitted. Though both Tel-

net and FTP connections are str eam oriented, they transmit using the same

device; the device doesn’t see the individual streams, but only the data pack-

ets.

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

a node in the ﬁlesystem, 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 ﬁlesystem. Communication

between the kernel and a network device driver is completely differ ent fr om

that used with char and block drivers. Instead of read and write, the kernel

calls functions related to packet transmission.

Other classes of driver modules exist in Linux. The modules in each class exploit

public services the kernel offers to deal with speciﬁc types of devices. Therefor e,

Classes of Devices and Modules

22 June 2001 16:32

Chapter 1: An Introduction to Device Driver s

one can talk of universal serial bus (USB) modules, serial modules, and so on. The

most common nonstandard class of devices is that of SCSI

drivers. Although every

peripheral connected to the SCSI bus appears in /dev as either a char device or a

block device, the internal organization of the software is dif ferent.

Just as network interface cards provide the network subsystem with hardware-

related functionality, so a SCSI controller provides the SCSI subsystem with access

to the actual interface cable. SCSI is a communication protocol between the com-

puter and peripheral devices, and every SCSI device responds to the same proto-

col, independently of what controller board is plugged into the computer. The

Linux kernel therefor e embeds a SCSI implementation (i.e., the mapping of ﬁle

operations to the SCSI communication protocol). The driver writer has to imple-

ment the mapping between the SCSI abstraction and the physical cable. This map-

ping depends on the SCSI controller and is independent of the devices attached to

the SCSI cable.

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

including USB drivers, FireWir e drivers, and I2O drivers. In the same way that they

handled 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.

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

ar e modularized in the kernel. Beyond device drivers, ﬁlesystems are perhaps the

most important class of modules in the Linux system. A ﬁlesystem type determines

how information is organized on a block device in order to repr esent a tree of

dir ectories and ﬁles. 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 ﬁlesystem type is

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

level data structures. It is the ﬁlesystem that determines how long a ﬁlename can

be and what information about each ﬁle is stored in a directory entry. The ﬁlesys-

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

tories and ﬁles, by mapping ﬁlenames and paths (as well as other information,

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

completely 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 ﬁlesystem,

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

to decode ﬁlesystem 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 concept of a ﬁlesystem module, whose software inter face declar es

the differ ent operations that can be perfor med on a ﬁlesystem inode, directory,

* SCSI is an acronym for Small Computer Systems Interface; it is an established standard in

the workstation and high-end server market.

22 June 2001 16:32

ﬁle, and superblock. It’s quite unusual for a programmer to actually need to write

a ﬁlesystem module, because the ofﬁcial kernel already includes code for the most

important ﬁlesystem types.

Secur ity Issues

Security is an increasingly important concern in moder n times. We will discuss

security-r elated issues as they come up throughout the book. There are a few gen-

eral concepts, however, that are worth mentioning now.

Security has two faces, which can be called deliberate and incidental. One security

pr oblem is the damage a user can cause through the misuse of existing programs,

or by incidentally exploiting bugs; a differ ent issue is what kind of (mis)functional-

ity a programmer can deliberately implement. The programmer has, obviously,

much more power than a plain user. In other words, it’s as dangerous to run a

pr ogram you got from somebody else from the root account as it is to give him or

her a root shell now and then. Although having access to a compiler is not a secu-

rity hole per se, the hole can appear when compiled code is actually executed;

everyone should be careful with modules, because a kernel module can do any-

thing. A module is just as powerful as a superuser shell.

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

security holes, then the system has holes. In the ofﬁcial kernel distribution, only

an authorized user can load modules; the system call cr eate_module checks if the

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

ning an ofﬁcial 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 ker-

nel, under the control of the system administrator. Ther e ar e always exceptions,

however. As a device driver writer, you should be aware of situations in which

some types of device access could adversely affect the system as a whole, and

should provide adequate controls. For example, device operations that affect

global resources (such as setting an interrupt line) or that could affect other users

(such as setting a default block size on a tape drive) are usually only available to

suf ﬁciently privileged users, and this check must be made in the driver itself.

Driver writers must also be careful, of course, to avoid introducing security bugs.

The C programming language makes it easy to make several types of errors. Many

curr ent security problems are created, for example, by buf fer overrun err ors, in

which the programmer forgets to check how much data is written to a buffer, and

data ends up written beyond the end of the buffer, thus overwriting unrelated

* Version 2.0 of the kernel allows only the superuser to run privileged code, while version

2.2 has more sophisticated capability checks. We discuss this in “Capabilities and

Restricted Operations” in Chapter 5.

Secur ity Issues

22 June 2001 16:32

Chapter 1: An Introduction to Device Driver s

data. Such errors can compromise the entire system and must be avoided. Fortu-

nately, avoiding these errors is usually relatively easy in the device driver context,

in which the interface to the user is narrowly deﬁned and highly controlled.

Some other general security ideas are worth keeping in mind. Any input received

fr om user processes should be treated with great suspicion; never trust it unless

you can verify it. Be careful with uninitialized memory; any memory obtained

fr om the kernel should be zeroed or otherwise initialized before being made avail-

able to a user process or device. Otherwise, information leakage could result. If

your device interprets data sent to it, be sure the user cannot send anything that

could compromise the system. Finally, think about the possible effect of device

operations; if there are speciﬁc operations (e.g., reloading the ﬁrmwar e on an

adapter board, formatting a disk) that could affect the system, those operations

should probably be restricted to privileged users.

Be careful, also, when receiving software from third parties, especially when the

ker nel is concerned: because everybody has access to the source code, everybody

can break and recompile things. Although you can usually trust precompiled ker-

nels found in your distribution, you should avoid running kernels compiled by an

untrusted friend—if you wouldn’t run a precompiled binary as root, then you’d

better not run a precompiled kernel. For example, a maliciously modiﬁed kernel

could allow anyone to load a module, thus opening an unexpected back door via

cr eate_module.

Note that the Linux kernel can be compiled to have no module support whatso-

ever, thus closing any related security holes. In this case, of course, all needed

drivers must be built directly into the kernel itself. It is also possible, with 2.2 and

later kernels, to disable the loading of kernel modules after system boot, via the

capability mechanism.

Version Numbering

Befor e digging into programming, we’d like to comment on the version number-

ing scheme used in Linux and which versions are cover ed by this book.

First of all, note that every softwar e package used in a Linux system has its own

release number, and there are often interdependencies across them: you need a

particular version of one package to run a particular version of another package.

The creators of Linux distributions usually handle the messy problem of matching

packages, and the user who installs from a prepackaged distribution doesn’t need

to deal with version numbers. Those who replace and upgrade system software,

on the other hand, are on their own. Fortunately, almost all modern distributions

support the upgrade of single packages by checking interpackage dependencies;

the distribution’s package manager generally will not allow an upgrade until the

dependencies are satisﬁed.

22 June 2001 16:32

To run the examples we introduce during the discussion, you won’t need particu-

lar versions of any tool but the kernel; any recent Linux distribution can be used

to run our examples. We won’t detail speciﬁc requir ements, because the ﬁle Docu-

mentation/Changes in your kernel sources is the best source of such information if

you experience any problem.

As far as the kernel is concerned, the even-numbered kernel versions (i.e., 2.2.x

and 2.4.x) are the stable ones that are intended for general distribution. The odd

versions (such as 2.3.x), on the contrary, are development snapshots and are quite

ephemeral; the latest of them repr esents the current status of development, but

becomes obsolete in a few days or so.

This book covers versions 2.0 through 2.4 of the kernel. Our focus has been to

show all the features available to device driver writers in 2.4, the current version at

the time we are writing. We also try to cover 2.2 thoroughly, in those areas where

the features differ between 2.2 and 2.4. We also note features that are not available

in 2.0, and offer workarounds where space permits. In general, the code we show

is designed to compile and run on a wide range of kernel versions; in particular, it

has all been tested with version 2.4.4, and, where applicable, with 2.2.18 and

2.0.38 as well.

This text doesn’t talk speciﬁcally about odd-numbered kernel versions. General

users will never have a reason to run development kernels. Developers experi-

menting with new features, however, will want to be running the latest develop-

ment release. They will usually keep upgrading to the most recent version to pick

up bug ﬁxes and new implementations of features. Note, however, that there’s no

guarantee on experimental kernels,

and nobody will help you if you have prob-

lems due to a bug in a noncurrent odd-numbered kernel. Those who run odd-

number ed versions of the kernel are usually skilled enough to dig in the code

without the need for a textbook, which is another reason why we don’t talk about

development kernels here.

Another feature of Linux is that it is a platform-independent operating system, not

just “a Unix clone for PC clones” anymore: it is successfully being used with Alpha

and SPARC processors, 68000 and PowerPC platforms, as well as a few more. This

book is platform independent as far as possible, and all the code samples have

been tested on several platforms, such as the PC brands, Alpha, ARM, IA-64, M68k,

PowerPC, SPARC, SPARC64, and VR41xx (MIPS). Because the code has been tested

on both 32-bit and 64-bit processors, it should compile and run on all other plat-

for ms. As you might expect, the code samples that rely on particular hardware

don’t work on all the supported platforms, but this is always stated in the source

code.

* Note that there’s no guarantee on even-numbered kernels as well, unless you rely on a

commercial provider that grants its own warranty.

Version Numbering

22 June 2001 16:32

剩余535页未读，继续阅读

gaohan330

粉丝: 0
资源: 1

探索Linux内核：设备驱动程序开发(第2版)

BeginningPython2ndEdition.part2.rar

InsideJava2PlatformSecurity2ndEdition.pdf

prob-solved_2ndedition.pdf

c程序设计语言英文第2版)prenticehall-thecprogramminglanguage2ndedition)

BeginningPython2ndEdition.part1.rar

CABeginnersGuide2ndEdition-英文原版.zip

EssentialSNMP2ndEdition.zip

Programming WPF 2ndEdition

ThinkingInC++2ndEdition

CFAQs2ndEdition-英文原版.zip

最新资源