linuxdevicedriver_devicedriver下载资源-CSDN文库

需积分: 9 8 浏览量 2010-11-08 03:48:06 上传评论收藏 646KB PDF 举报

This is, on the surface, a book about writing device drivers for the Linux system. That is a worthy goal, of course; the flow of new hardware products is not likely to slow down anytime soon, and somebody is going to have to make all those new gadgets work with Linux. But this book is also about how the Linux kernel works and how to adapt its workings to your needs or interests. Linux is an open system; with this book, we hope, it is more open and accessible to a larger community of developers. This is the third edition of Linux Device Drivers. The kernel has changed greatly since this book was first published, and we have tried to evolve the text to match. This edition covers the 2.6.10 kernel as completely as we are able. We have, this time around, elected to omit the discussion of backward compatibility with previous kernel versions. The changes from 2.4 are simply too large, and the 2.4 interface remains well documented in the (freely available) second edition. This edition contains quite a bit of new material relevant to the 2.6 kernel. The discussion of locking and concurrency has been expanded and moved into its own chapter. The Linux device model, which is new in 2.6, is covered in detail. There are new chapters on the USB bus and the serial driver subsystem; the chapter on PCI has also been enhanced. While the organization of the rest of the book resembles that of the earlier editions, every chapter has been thoroughly updated. We hope you enjoy reading this book as much as we have enjoyed writing it. ### Linux Device Driver 相关知识点 #### 一、书籍概览 - **书籍名称**：Linux Device Drivers（第三版） - **出版年份**：2005年 - **出版社**：O'Reilly & Associates, Inc. - **版权声明**：所有权利保留 #### 二、书籍内容概述本书旨在教授读者如何为Linux系统编写设备驱动程序。它不仅涵盖了设备驱动程序的编写技巧，还深入探讨了Linux内核的工作原理及其如何适应开发者的特定需求或兴趣。本书特别强调了Linux作为一个开放系统的特性，并希望通过本书使更多的开发者能够更好地理解和利用Linux内核。 #### 三、书籍特点 - **覆盖范围**：本书主要聚焦于2.6.10版本的Linux内核。 - **新特性介绍**：本书新增了大量的与2.6内核相关的新材料，包括锁和并发控制的扩展章节、新的Linux设备模型、USB总线以及串行驱动子系统等内容。 - **组织结构**：尽管本书整体结构与前两版相似，但每一章都经过了彻底更新。 #### 四、新增内容 - **锁和并发控制**：新增了一整章专门讨论锁和并发控制机制，这对于处理多处理器环境下的并发问题非常重要。 - **Linux设备模型**：2.6内核引入了全新的设备模型，本书对此进行了详细解释。 - **USB总线和串行驱动子系统**：新增了关于USB总线和串行驱动子系统的章节，帮助开发者更好地理解这些硬件接口的工作原理和驱动程序设计。 - **PCI章节增强**：对于PCI总线的支持和相关的编程细节进行了增强。 #### 五、模块开发基础 - **第2章内容**：本书第二章介绍了模块开发的基础知识，包括构建和运行模块的基本概念。本章通过一个简单的示例模块来介绍核心概念，并不涉及具体的设备类别。 - **测试系统设置**：建议读者在标准的Linux内核上进行开发，避免使用经过大量定制的发行版内核，因为这些内核可能会有API变化，影响驱动程序的兼容性。 - **构建要求**：为了构建2.6.x版本的模块，需要有一个配置好并编译完成的内核源码树。这是因为2.6版本的模块需要链接内核源码树中的对象文件。 #### 六、关键概念 - **模块**：独立的代码块，可以动态地加载到内核中或从中卸载，以实现特定功能。 - **锁和并发控制**：用于管理多个处理器之间资源访问的机制，确保数据的一致性和完整性。 - **设备模型**：内核中用于管理各种硬件设备的一套框架，提供统一的接口以简化设备驱动的编写。 - **USB总线和串行驱动**：分别针对USB总线设备和串行通信设备的驱动支持。 - **PCI**：一种常见的计算机总线标准，用于连接高速外设到计算机主板。 #### 七、结论《Linux Device Drivers》第三版是一本全面而深入的书籍，不仅适合希望为Linux系统编写设备驱动的开发者，也适用于对Linux内核工作原理感兴趣的任何人。本书提供了丰富的实践指导和理论知识，是学习Linux设备驱动开发不可或缺的资源。

资源推荐

资源详情

资源评论

This is the Title of the Book, eMatter Edition

Chapter 2

CHAPTER 2

Building and Running

Modules

It’s almost time to begin programming. This chapter introduces all the essential con-

cepts about modules and kernel programming. In these few pages, we build and run

a complete (if relatively useless) module, and look at some of the basic code shared

by all modules. Developing such expertise is an essential foundation for any kind of

modularized driver. To avoid throwing in too many concepts at once, this chapter

talks only about modules, without referring to any specific device class.

All the kernel items (functions, variables, header files, and macros) that are intro-

duced here are described in a reference section at the end of the chapter.

Setting Up Your Test System

Starting with this chapter, we present example modules to demonstrate program-

ming concepts. (All of these examples are available on O’Reilly’s FTP site, as

explained in Chapter 1.) Building, loading, and modifying these examples are a good

way to improve your understanding of how drivers work and interact with the kernel.

The example modules should work with almost any 2.6.x kernel, including those

provided by distribution vendors. However, we recommend that you obtain a “main-

line” kernel directly from the kernel.org mirror network, and install it on your sys-

tem. Vendor kernels can be heavily patched and divergent from the mainline; at

times, vendor patches can change the kernel API as seen by device drivers. If you are

writing a driver that must work on a particular distribution, you will certainly want

to build and test against the relevant kernels. But, for the purpose of learning about

driver writing, a standard kernel is best.

Regardless of the origin of your kernel, building modules for 2.6.x requires that you

have a configured and built kernel tree on your system. This requirement is a change

from previous versions of the kernel, where a current set of header files was suffi-

cient. 2.6 modules are linked against object files found in the kernel source tree; the

result is a more robust module loader, but also the requirement that those object files

,ch02.6536 Page 15 Friday, January 21, 2005 10:32 AM

This is the Title of the Book, eMatter Edition

Chapter 2: Building and Running Modules

be available. So your first order of business is to come up with a kernel source tree

(either from the kernel.org network or your distributor’s kernel source package),

build a new kernel, and install it on your system. For reasons we’ll see later, life is

generally easiest if you are actually running the target kernel when you build your

modules, though this is not required.

You should also give some thought to where you do your module

experimentation, development, and testing. We have done our best to

make our example modules safe and correct, but the possibility of

bugs is always present. Faults in kernel code can bring about the

demise of a user process or, occasionally, the entire system. They do

not normally create more serious problems, such as disk corruption.

Nonetheless, it is advisable to do your kernel experimentation on a

system that does not contain data that you cannot afford to lose, and

that does not perform essential services. Kernel hackers typically keep

a “sacrificial” system around for the purpose of testing new code.

So, if you do not yet have a suitable system with a configured and built kernel source

tree on disk, now would be a good time to set that up. We’ll wait. Once that task is

taken care of, you’ll be ready to start playing with kernel modules.

The Hello World Module

Many programming books begin with a “hello world” example as a way of showing

the simplest possible program. This book deals in kernel modules rather than pro-

grams; so, for the impatient reader, the following code is a complete “hello world”

module:

#include <linux/init.h>

#include <linux/module.h>

MODULE_LICENSE("Dual BSD/GPL");

static int hello_init(void)

{

printk(KERN_ALERT "Hello, world\n");

return 0;

}

static void hello_exit(void)

{

printk(KERN_ALERT "Goodbye, cruel world\n");

}

module_init(hello_init);

module_exit(hello_exit);

This module defines two functions, one to be invoked when the module is loaded

into the kernel (hello_init) and one for when the module is removed (hello_exit). The

,ch02.6536 Page 16 Friday, January 21, 2005 10:32 AM

This is the Title of the Book, eMatter Edition

The Hello World Module

module_init and module_exit lines use special kernel macros to indicate the role of

these two functions. Another special macro (MODULE_LICENSE) is used to tell the

kernel that this module bears a free license; without such a declaration, the kernel

complains when the module is loaded.

The printk function is defined in the Linux kernel and made available to modules; it

behaves similarly to the standard C library function printf. The kernel needs its own

printing function because it runs by itself, without the help of the C library. The

module can call printk because, after insmod has loaded it, the module is linked to

the kernel and can access the kernel’s public symbols (functions and variables, as

detailed in the next section). The string

KERN_ALERT is the priority of the message.

We’ve specified a high priority in this module, because a message with the default

priority might not show up anywhere useful, depending on the kernel version you

are running, the version of the klogd daemon, and your configuration. You can

ignore this issue for now; we explain it in Chapter 4.

You can test the module with the insmod and rmmod utilities, as shown below. Note

that only the superuser can load and unload a module.

% make

make[1]: Entering directory `/usr/src/linux-2.6.10'

CC [M] /home/ldd3/src/misc-modules/hello.o

Building modules, stage 2.

MODPOST

CC /home/ldd3/src/misc-modules/hello.mod.o

LD [M] /home/ldd3/src/misc-modules/hello.ko

make[1]: Leaving directory `/usr/src/linux-2.6.10'

% su

root# insmod ./hello.ko

Hello, world

root# rmmod hello

Goodbye cruel world

root#

Please note once again that, for the above sequence of commands to work, you must

have a properly configured and built kernel tree in a place where the makefile is able

to find it (/usr/src/linux-2.6.10 in the example shown). We get into the details of how

modules are built in the section “Compiling and Loading.”

According to the mechanism your system uses to deliver the message lines, your out-

put may be different. In particular, the previous screen dump was taken from a text

console; if you are running insmod and rmmod from a terminal emulator running

under the window system, you won’t see anything on your screen. The message goes

to one of the system log files, such as /var/log/messages (the name of the actual file

* The priority is just a string, such as <1>, which is prepended to the printk format string. Note the lack of a

comma after KERN_ALERT; adding a comma there is a common and annoying typo (which, fortunately, is

caught by the compiler).

,ch02.6536 Page 17 Friday, January 21, 2005 10:32 AM

This is the Title of the Book, eMatter Edition

Chapter 2: Building and Running Modules

varies between Linux distributions). The mechanism used to deliver kernel messages

is described in Chapter 4.

As you can see, writing a module is not as difficult as you might expect—at least, as

long as the module is not required to do anything worthwhile. The hard part is

understanding your device and how to maximize performance. We go deeper into

modularization throughout this chapter and leave device-specific issues for later

chapters.

Kernel Modules Versus Applications

Before we go further, it’s worth underlining the various differences between a kernel

module and an application.

While most small and medium-sized applications perform a single task from begin-

ning to end, every kernel module just registers itself in order to serve future requests,

and its initialization function terminates immediately. In other words, the task of the

module’s initialization function is to prepare for later invocation of the module’s

functions; it’s as though the module were saying, “Here I am, and this is what I can

do.” The module’s exit function (hello_exit in the example) gets invoked just before

the module is unloaded. It should tell the kernel, “I’m not there anymore; don’t ask

me to do anything else.” This kind of approach to programming is similar to event-

driven programming, but while not all applications are event-driven, each and every

kernel module is. Another major difference between event-driven applications and

kernel code is in the exit function: whereas an application that terminates can be lazy

in releasing resources or avoids clean up altogether, the exit function of a module

must carefully undo everything the init function built up, or the pieces remain

around until the system is rebooted.

Incidentally, the ability to unload a module is one of the features of modularization

that you’ll most appreciate, because it helps cut down development time; you can

test successive versions of your new driver without going through the lengthy shut-

down/reboot cycle each time.

As a programmer, you know that an application can call functions it doesn’t define:

the linking stage resolves external references using the appropriate library of func-

tions. printf is one of those callable functions and is defined in libc. A module, on the

other hand, is linked only to the kernel, and the only functions it can call are the

ones exported by the kernel; there are no libraries to link to. The printk function

used in hello.c earlier, for example, is the version of printf defined within the kernel

and exported to modules. It behaves similarly to the original function, with a few

minor differences, the main one being lack of floating-point support.

Figure 2-1 shows how function calls and function pointers are used in a module to

add new functionality to a running kernel.

,ch02.6536 Page 18 Friday, January 21, 2005 10:32 AM

This is the Title of the Book, eMatter Edition

Kernel Modules Versus Applications

Because no library is linked to modules, source files should never include the usual

header files, <stdarg.h> and very special situations being the only exceptions. Only

functions that are actually part of the kernel itself may be used in kernel modules.

Anything related to the kernel is declared in headers found in the kernel source tree

you have set up and configured; most of the relevant headers live in include/linux and

include/asm, but other subdirectories of include have been added to host material

associated to specific kernel subsystems.

The role of individual kernel headers is introduced throughout the book as each of

them is needed.

Another important difference between kernel programming and application pro-

gramming is in how each environment handles faults: whereas a segmentation fault

is harmless during application development and a debugger can always be used to

trace the error to the problem in the source code, a kernel fault kills the current pro-

cess at least, if not the whole system. We see how to trace kernel errors in Chapter 4.

User Space and Kernel Space

A module runs in kernel space, whereas applications run in user space. This concept

is at the base of operating systems theory.

The role of the operating system, in practice, is to provide programs with a consis-

tent view of the computer’s hardware. In addition, the operating system must

account for independent operation of programs and protection against unauthorized

access to resources. This nontrivial task is possible only if the CPU enforces protec-

tion of system software from the applications.

Figure 2-1. Linking a module to the kernel

init functioninsmod

blk_init_queue()

add_disk()

request()

block_device ops

cleanup

function

rmmod

del_gendisk()

blk_cleanup_queue()

request_queue_

struct

gendisk

Data operation

Data pointer

Function call

Function pointer

Multiple functions

Single functions

Data

,ch02.6536 Page 19 Friday, January 21, 2005 10:32 AM

剩余26页未读，继续阅读

评论收藏

内容反馈

pchrys

粉丝: 0
资源: 4

linux device driver

最新资源

linux device driver

Linux Device Drivers / Linux 设备驱动程序(第三版)

Linux device driver中文版.pdf

The Windows NT Device Driver Book

Packt.Linux.Device.Drivers.Development.2017

Linux Device Driver / Essential Linux Device Drivers 中文版

【Linux Device Driver】(3edtion).pdf

linux device drivers

Linux device drivers

linux device driver（linux设备驱动）

linux设备驱动程序

Linux Device Driver

Linux Device Driver3

linux device driver v3 chm chinese

linux device driver3 ldd3 code

linux device driver 3th edition

Linux Device Driver Development

Linux Device Driver(3rd Edition)

linux-device-driver

最新资源