驱动程序的编写过程,驱动程序如何编写
如何在 Windows CE 5.0 中开发和测试设备驱动程序
本文介绍如何开发和测试 Windows CE 5.0 设备驱动程序。本文循序渐进地介绍如何创建流驱动程序，如何创建自定义 Windows CE Test Kit
(CETK) 测试，以及如何编写应用程序来测试驱动程序。这要花费大约 60 分钟来完成。
本页内容
第一部分：建立设备驱动程序
第二部分：测试流驱动程序测试代码
第三部分：检验驱动程序
第四部分：使用
Windows CE Test Kit
第五部分：创建自定义
CETK 测试
第六部分：确定谁拥有流驱动程序
小结
第一部分：建立设备驱动程序
在本练习中，您将使用 Platform Builder 来添加作为设备驱动程序的项目。
在 开始编写驱动程序之前，您应该了解设备驱动程序的用途。驱动程序将基础硬件从操作系统中抽象出来，使之更好地面对应用程序开发人员。应用程序开发人员无需
知道显示硬件或串行硬件的详细信息 — 例如，串行设备是用 Universal Asynchronous Receiver/Transmitter (UART)
实现的还是用 field-programmable gate array (FPGA)
实现的。在大多数情况下，应用程序开发人员根本不需要知道硬件是如何实现的。
Microsoft Windows 为开发人员公开了调用硬件的应用程序编程接口
(API)，他们不需要知道物理硬件的情况。例如，为了向串行端口写入数据，应用程序开发人员只需调用 COMx 上的 CreateFile( )（其中 x
表示您要打开的串行端口编号，例如 COM1 代表串行端口 1），再调用 WriteFile( ) 以将一些字节数据写入串行端口，然后调用
CloseHandle( ) 以关闭串行端口。不管基础串行硬件是什么（也不管您运行的是哪个 Windows 操作系统），API 都会以同样的顺序执行。
相同的情况也适用于其他 API：如果您希望在显示表面画一条线，那么您只需调用 PolyLine( )、MoveToEx( ) 或 LineTo(
)。作为应用程序开发人员，大多数情况下您都不需要知道显示硬件的情况。此处调用的 API 将返回显示表面的维数、颜色深度等等。
好 消息是开发人员可以调用一个一致的、众所周知的 API 集。这些 API
将他们的应用程序从基础硬件中抽象出来。这至关重要，因为应用程序开发人员无法知道应用程序是运行在便携式计算机上，还是运行在 Tablet PC
上，抑或运行在桌面计算机上。无论电脑以 1024×768 还是 1600×1200
的分辨率运行，应用程序开发人员都可以在运行时查询屏幕分辨率和颜色深度，因此不需要构建只在特定硬件上运行的应用程序。
驱动程序只是一 个动态链接库(DLL)。将 DLL 加载到父进程地址空间；然后父进程就可以调用从该 DLL 公开的任何接口。通常，父进程通过调用
LoadLibrary( ) 或 LoadDriver( ) 来加载驱动程序。LoadDriver 不仅将 DLL 加载到父进程地址空间中，而且还要确保 DLL
没有“paged out”。
调用进程如何知道从您的 DLL 或驱动程序公开了哪些 API 或函数呢？父进程调用 GetProcAddress( )，后者可以获取函数名称和所加载的
DLL 的 hInstance。如果函数存在，调用返回该函数指针；如果没有从 DLL 公开该函数，则返回 NULL。
流驱动程序也公开了一个众所周知的函数集。对于流驱动程序，您会希望能够将字节流写入设备中，或者从设备中读取字节流。因此，在前面使用的串行端口示例中，您可能希望从您的驱动程序公开如下函数集：Open、Close、Read
和
Write。流驱动程序还公开一些其他函数：PowerUp、PowerDown、IOControl、Init
和 DeInit。
您可以将现有的操作系统映像用于模拟器平台（Basic Lab MyPlatform 平台最理想）。然后，您就可以将
DLL/驱动程序项目添加到该平台了。
在构建并下载了该平台之后（这表明操作系统启动并运行良好），您需要创建您的主干驱动程序。您可以使用 File 菜单上的 Platform
Builder New Project or File 命令创建一个 Microsoft Windows CE DLL。创建用于公开函数或资源的
DLL 与创建用作驱动程序的 DLL 之间没有什么不同；唯一的不同之处在于 DLL 公开哪些函数，以及如何在平台上注册或使用 DLL。
此 外，一种创建国际化应用程序的方法是，首先创建包含一组核心语言字符串、对话框和资源的基本应用程序，然后创建许多外部
DLL，其中每个都包含针对特定区域设置的对话框、字符串和资源。然后，应用程序就可以在运行时加载相应的语言资源。只需要添加 DLL
文件，您就可以将语言添加到应用程序中。在 Developing International
Software 一书中描述了与此相关的主题以及其他一些有趣的主题，可以在 Microsoft Press 网站上获得此书。
添加一个作为设备驱动程序的项目
用 Platform Builder 打开现有的 MyPlatform 工作区。
在 File 菜单上，单击 New Project or File。
选择 WCE Dynamic-Link Library，给它一个合适的名称（例如，StreamDrv），然后单击
OK，如下图所示。
在下图所显示的页面中多少填写一些您需要的信息，然后单击 Next。
单击 A simple Windows CE DLL project，如下图所示。
单击 Finish 完成此向导。
此时，DLL 只包含一个空的 DllMain
函数。您可以公开一些应用程序要调用的函数，并公开一些资源（可能使之成为识别语言/文化的应用程序的一部分），或者使之成为一个设备驱动程序。在本文中，您将使用
Windows CE Stream Driver Wizard 创建您的主干流驱动程序。
在 Windows CE 中，打开流驱动程序就像打开文件一样，只需根据唯一的三字母前缀（例如，COM）。
为您的驱动程序选择一个唯一的三字母标识符。在 Location
框中输入您之前创建的流驱动程序的完整路径。或者使用“browse”按钮定位到 Platform Builder 安装中的 PBWorkspaces
目录，找到您前面创建的平台，然后找到流驱动程序的名称（在前面的示例中，此路径为 PBWorkspaces\TuxPlat\StreamDrv）。
在 Driver Filename 框中输入驱动程序的名称。如下图所示，使用与您前面使用名称 (StreamDrv)
相同的名称，以确保改写在 Platform Builder 中创建的原始文件。
按 Go，将生成流驱动程序源代码。
返回页首
第二部分：测试流驱动程序测试代码
现在您已经编写了用于 Windows CE 的自定义流驱动程序的基本代码。此时，驱动程序还没有与任何硬件连接。
在 编写完驱动程序之后，您需要为开发人员提供一种测试它的方法。Windows CE 附带了 Windows CE Test Kit
(CETK)，它提供了用于各种驱动程序类型的驱动程序测试，包含网络连接、蓝牙、串行端口以及显示。您编写的驱动程序是一种自定义的流驱动程序，它没有
公开与现有的驱动程序测试一样的功能，因此您需要为该驱动程序编写一个自定义测试。虽然您完全可以编写一个应用程序来演练驱动程序，但提供一个 CETK
模块或许更好些，在开发期间可以使用此模块，并且还可以将此模块提供给客户，供他们在装配硬件上测试驱动程序。
在这一部分的练习中，您将执行以下过程：
创建主干 Tux 模块
将自定义驱动程序的测试代码添加到 Tux DLL 中
重新构建操作系统
设置断点
创建主干 Tux 模块
在 Platform Builder 中，在 File 菜单上单击 New Project or File。
选择 WCE TUX Dynamic-Link Library，键入 TuxTest 作为项目名称，输入一个位置，单击
Workspace Project，然后单击 OK，如下图所示。（实际上，您可以选择任意一个项目类型；对于本文，单击
Workspace Project）。
在下图显示的页面中多少填写一些您需要的信息，然后单击 Next。
阅读下图所显示的屏幕上的信息，然后单击 Next。
在最后一页上，您可以选择选取 Release Type 下的
CETK，如下图所示。该选项关闭了某些二进制的优化，以提高调试工作效率。单击 Finish。
单击 View | File View，然后展开 Projects 树显示 tux
源代码，如下图所示。
前图中需要注意的重要文件是：
ft.h — 该文件包含 tux DLL 所用的函数表。
test.cpp — 该文件包含从该函数表中调用的测试过程。
TuxStreamTest.cpp — 该文件包含 DLLMain 和 ShellProc，后者是从 Tux.exe
调用的。
将自定义驱动程序测试代码添加到 Tux DLL 中
打开源代码 Test.cpp。
使用 CodeClip 来获得 Tux_Custom_Test | TuxCode 源代码。
用 CodeClip 中的代码替代函数 TestProc 中的内容。
您会注意到，Test.cpp 中的代码加载了一个名为 Demo.dll 的驱动程序。对于本文，您创建了一个名为 StreamDrv
的驱动程序。您需要修改源代码以加载您的 StreamDrv.dll 驱动程序。
找到 Test.cpp 中调用 LoadLibrary 的源代码的位置，然后将要从 Demo.dll
中加载的驱动程序的名称修改为 StreamDrv.dll。
在 Platform Builder 文件视图中，右键单击 TuxTest 项目，然后单击 Build Current
Project。
您还需要从该目录中添加 Windows CE Test Kit 组件。
在 Device Drivers 下，找到该目录中 Windows CE Test Kit 组件的位置，然后选择
Add the Windows CE Test Kit，将该组件添加到您的平台中。
注 将该组件添加到您的平台上并没有将任何文件添加到最后的操作系统映像中；它将 Clientside 文件添加到 build release
文件夹中。您可以从 Platform Builder 下载 Clientside 应用程序，并在目标设备上运行该应用程序。
现在您需要重新构建您的操作系统，以便合并这些变更。
重新构建操作系统
在 Platform Builder 中，选择 Build OS | Sysgen。
构建过程将会花大约 5 分钟完成。
当加载驱动程序时，在流驱动程序的入口点设置一个断点来观察非常有用。
设置断点
单击 File View，打开 StreamDrv 项目，然后打开 Source files。
找到并打开 StreamDrv.cpp。
找到 DllMain，然后找到并单击 switch 语句。
按 F9 设置断点。
单击 Target | Attach，将操作系统下载到模拟环境中。
您会看到以下调试输出，断点将启用。注意，在加载操作系统的用户接口 (UI) 之前，这早就发生了。
4294780036 PID:23f767b6 TID:23f767e6 0x83fa6800: Loading module
streamdrv.dll at address 0x01ED0000-0x01ED5000
Loaded symbols for
'C:\WINCE500\PBWORKSPACES\DRVDEMO\RELDIR\EMULATOR_X86_DEBUG\STREAMDRV.DLL'
单击 switch 语句，然后按 F9 禁用断点。
按 F5，允许操作系统继续加载。
现在，您已经构建了一个 Windows CE 5.0
操作系统，它包含一个自定义流驱动程序，并且您已经在操作系统引导顺序的过程中看到了驱动程序加载。
返回页首
第三部分：检验驱动程序
在这一部分的练习中，您将执行以下过程：
使用命令行工具查看从驱动程序公开的函数
使用远程系统信息 (Remote System Information) 工具检验驱动程序
确定驱动程序已加载
检验您所创建的设备驱动程序的第一种方法是查看从该驱动程序公开的函数。Windows CE 附带了一个名为 Dumpbin
的命令行工具，可以用于检验导入应用程序或模块的内容，或者从 DLL（或驱动程序）导出的内容。
使用命令行工具查看从驱动程序公开的函数
在 Platform Builder 中，单击 Build OS | Open Release
Directory。该操作为当前的工作区打开 build release 文件夹中的 Command Prompt 窗口。
键入 dumpbin exports StreamDrv.dll
下图显示输出。您可以看到，所有需要的流驱动程序函数都是从驱动程序公开的；函数是从 DLL 公开的（通过该项目的 .def 文件）。
键入 Exit 关闭 Command Prompt 窗口
StreamDrv.def 文件的内容如下所示。
LIBRARY DemoDriver
EXPORTS
DEM_Init
DEM_Deinit
DEM_Open
DEM_Close
DEM_IOControl
DEM_PowerUp
DEM_PowerDown
DEM_Read
DEM_Write
DEM_Seek
CustomFunction
CustomFunctionEx
您可以检验驱动程序的第二种方法是通过远程系统信息工具。
通过远程系统信息工具检验驱动程序
在 Platform Builder 中，单击 Tools | Remote System
Information。
选择 Windows CE Default Platform | Default Device，然后单击
OK，如下图所示。
此过程将远程系统信息应用程序连接到 Platform Builder 正在使用的当前活动平台上。下图显示了结果。
您也可以使用加载模块列表来确定已加载了您的驱动程序。
确定驱动程序已加载
在 Platform Builder 中，使用 Target Control 窗口 (gi mod) 或 View |
Debug Windows | Modules and Symbols。
下图显示了此过程的结果。
返回页首
第四部分：使用 Windows CE Test Kit
Windows CE Test Kit 包含设备端组件和桌面组件。设备端组件叫做 Clientside.exe，通过从目录中添加 CETK
组件，您可以将设备端组件添加到您的工作区中。注意，将 Clientside.exe
应用程序添加到工作区中并没有将任何文件添加到最终操作系统映像中，但它却将应用程序复制到 build release 文件夹中。
在桌面计算机上运行 CETK 之前，您需要启动设备上的 Clientside.exe 应用程序。没有链接工具（比如远程工具）的原因在于，CETK
也将运行在装配（零售）设备（比如 Pocket PC）上。
在这一部分的练习中，您将执行以下过程：
检验 Windows CE Test Kit 用户接口
运行一个标准测试
检验 Windows CE Test Kit 用户接口
在 Platform Builder 中，在 Tools 菜单上单击 Windows CE Test
Kit。
这 一步启动 Windows CE Test Kit 应用程序，如下图所示。注意，这不是一个标准的远程工具。Windows CE
附带的大多数远程工具都使用 Kernel Independent Transport Layer
(KITL)，一种将工具从基础通信硬件中抽象出来的传输，以便这些工具可以运行在以太网、串行端口、1394、USB 或者其他传输上。
虽然对于 Windows CE 5.0，Windows CE Test Kit 通常通过套接字连接，但是也已经更新了工具来支持 KITL。
在 Windows CE Test Kit 中，单击 Connection | Start
Client。
这一步显示 Device Connection 对话框，其中您可以选择是通过套接字连接还是通过 KITL 连接。
确保清除了 Use Windows Sockets for the client/server communication
复选框，如下图所示。
单击 Connect。
在远程工具 (KITL) 的标准用户界面中，选择 Windows CE Default Platform | Default
Device，然后单击 OK，如下图所示。
该过程在目标设备上启动 Clientside.exe，并连接到目标设备上。在完成连接之后，CETK 枚举目标平台上支持的设备，并禁用 CETK
中不支持的设备。
在 CETK 连接到目标设备并枚举设备之后，UI 如下图所示。注意，禁用了某些硬件类别，比如 Bluetooth、IR
Port 和 Modem。
将自定义测试添加到 CETK 中之前，您可以运行一个标准测试，以查看测试工作如何进行。
运行标准测试
在 CETK 中，展开 Windows CE (x86)。
找到并展开 Serial Port。
右键单击 Serial Port Driver Test，然后单击 Quick Start。
这一步只运行了这一个测试，还没有运行所选的其他测试。UI 指示测试正在进行，如下图所示。
CETK 提供测试过程和测试输出的更新。您也可以在 Platform Builder 中检验调试输出，以便查看测试过程，如下例所示。
405910 PID:83d4ee4a TID:83ea5a8a *** Test Name: Set event mask and wait for
thread to close comm port handle
405920 PID:83d4ee4a TID:83ea5a8a *** Test ID: 1007
405920 PID:83d4ee4a TID:83ea5a8a *** Library Path: \serdrvbvt.dll
405920 PID:83d4ee4a TID:83ea5a8a *** Command Line:
405920 PID:83d4ee4a TID:83ea5a8a *** Result: Passed
405920 PID:83d4ee4a TID:83ea5a8a *** Random Seed: 15595
405930 PID:83d4ee4a TID:83ea5a8a *** Thread Count: 1
405930 PID:83d4ee4a TID:83ea5a8a *** Execution Time: 0:00:05.110
405930 PID:83d4ee4a TID:83ea5a8a ***
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
如果 CETK UI
指示模拟器上的串行端口测试已经失败（如下图所示），那么失败可能不是由于每个测试的完全失败而导致的。它可能表明，全部测试套件只有一部分已经失败，并且这部分实际上也是期望的行为。
右键单击 Serial Port Driver Test [Failed]，然后单击 View
Results。
出现如下图所示的窗口。
查看上图所示的结果，您可以看到，已经运行了 10 个单独的测试。除了 Set and verify receive timeout
以外，所有这些测试都已经通过。
要获得更多信息，您可以单击个别测试。
返回页首
第五部分：创建自定义 CETK 测试
通过使用 Platform Builder User-Defined Test Wizard，您可以创建一个自定义 CETK
测试。该测试将验证自定义流驱动程序（您也已经将其添加到平台中）的导出函数。
在这一部分的练习中，您将执行以下过程：
列出 CETK 中的自定义流驱动程序测试
运行自定义流驱动程序测试
列出 CETK 中的自定义流驱动程序测试
在 CETK 中，单击 Tests | User Defined。
这一步启动 User-Defined Test Wizard。该向导的第一页只是一些信息。
单击 Next，如下图所示。
单击 Add a New Test，然后单击 Next，如下图所示。
输入下列信息，然后单击 Next：
· 在 Name of Test 框中键入 Custom Stream Driver Test
· 在 Tux Module (DLL) 框中，定位到
C:\Wince500\PBWorkspaces\MyPlatform\RelDir\Emulator_x86_Debug 目录，然后选择
test.dll 或 TuxTest.dll（这依赖于您在 Platform Builder 中所使用的 Tux
测试的名称）。
· 在 Command Line 框中，保留当前测试的默认设置。
· 在 Processor 框中键入 x86
下图显示信息如何出现在当前的向导页中。
单击 Copy the files to the directory for user-defined tests，然后单击
Next，如下图所示。
您需要将自定义驱动程序测试（您的 DLL）复制到用户定义的测试文件夹中。如果您要删除现有的工作区，那么自定义驱动程序测试仍然保持完好。
单击 Next，如下图所示。
单击 Finish，如下图所示。
CETK 应用程序不会用新的测试进行自动刷新。您需要重新同步桌面应用程序，以查看新添加的测试。
右键单击 Windows CE (x86)，然后单击 Redetect Peripherals。
该过程添加了一个名为 User Tests 的新驱动程序类别。您只添加了一个测试，因此，当您展开这个项目时，您只能看到 Custom
Stream Driver Test。
注 已经将自定义流驱动程序测试的 DLL 复制到下列位置： C:\Program Files\Windows CE Platform
Builder\5.00\CEPB\wcetk\user\x86.
运行自定义流驱动程序测试
在可用的测试列表中展开 User Tests。
右键单击 Custom Stream Driver Test，然后单击 Quick Start。
如何 编写 linux 驱动 程序
Linux是Unix操作系统的一种变种，在Linux下编写驱动程序的原理和思想完全类似于其他的Unix系统，但它dos或window环境下的驱动程序有很大的区别。在Linux环境下设计驱动程序，思想简洁，操作方便，功能也很强大，但是支持函数少，只能依赖kernel中的函数，有些常用的操作要自己来编写，而且调试也不方便。本人这几周来为实验室自行研制的一块多媒体卡编制了驱动程序，获得了一些经验，愿与Linux fans共享一、Linux device driver 的概念系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件的细节，这样在应用程序看来，硬件设备只是一个设备文件， 应用程序可以象操作普通文件一样对硬件设备进行操作。设备驱动程序是内核的一部分，它完成以下的功能：1.对设备初始化和释放。2.把数据从内核传送到硬件和从硬件读取数据。3.读取应用程序传送给设备文件的数据和回送应用程序请求的数据。4.检测和处理设备出现的错误。二、实例剖析我们来写一个最简单的字符设备驱动程序。虽然它什么也不做，但是通过它可以了解Linux的设备驱动程序的工作原理。
嵌入式驱动开发的基本流程
驱动一般过程是这样的：
首先了解你需要做的驱动的设备的规格，详细看看手册
了解设备的使用方法，通常厂家会提供一个测试的驱动程序源代码，
在你所移植的系统上编译驱动程序源代码，按照手册进行测试
然后再根据自己的需要修改相关代码
如何编写网卡的驱动程序
Linux操作系统网络驱动程序编写
一.Linux系统设备驱动程序概述
1.1 Linux设备驱动程序分类
1.2 编写驱动程序的一些基本概念
二.Linux系统网络设备驱动程序
2.1 网络驱动程序的结构
2.2 网络驱动程序的基本方法
2.3 网络驱动程序中用到的数据结构
2.4 常用的系统支持
三.编写Linux网络驱动程序中可能遇到的问题
3.1 中断共享
3.2 硬件发送忙时的处理
3.3 流量控制(flow control)
3.4 调试
四.进一步的阅读
五.杂项
一.Linux系统设备驱动程序概述
1.1 Linux设备驱动程序分类
Linux设备驱动程序在Linux的内核源代码中占有很大的比例，源代码的长度日
益增加，主要是驱动程序的增加。在Linux内核的不断升级过程中，驱动程序的结构
还是相对稳定。在2.0.xx到2.2.xx的变动里，驱动程序的编写做了一些改变，但是
从2.0.xx的驱动到2.2.xx的移植只需做少量的工作。
Linux系统的设备分为字符设备(char device)，块设备(block device)和网络
设备(network device)三种。字符设备是指存取时没有缓存的设备。块设备的读写
都有缓存来支持，并且块设备必须能够随机存取(random access)，字符设备则没有
这个要求。典型的字符设备包括鼠标，键盘，串行口等。块设备主要包括硬盘软盘
设备，CD-ROM等。一个文件系统要安装进入操作系统必须在块设备上。
网络设备在Linux里做专门的处理。Linux的网络系统主要是基于BSD unix的socket
机制。在系统和驱动程序之间定义有专门的数据结构(sk_buff)进行数据的传递。系
统里支持对发送数据和接收数据的缓存，提供流量控制机制，提供对多协议的支持。
1.2 编写驱动程序的一些基本概念
无论是什么操作系统的驱动程序，都有一些通用的概念。操作系统提供给驱动
程序的支持也大致相同。下面简单介绍一下网络设备驱动程序的一些基本要求。
1.2.1 发送和接收
这是一个网络设备最基本的功能。一块网卡所做的无非就是收发工作。所以驱
动程序里要告诉系统你的发送函数在哪里，系统在有数据要发送时就会调用你的发
送程序。还有驱动程序由于是直接操纵硬件的，所以网络硬件有数据收到最先能得
到这个数据的也就是驱动程序，它负责把这些原始数据进行必要的处理然后送给系
统。这里，操作系统必须要提供两个机制，一个是找到驱动程序的发送函数，一个
是驱动程序把收到的数据送给系统。
1.2.2 中断
中断在现代计算机结构中有重要的地位。操作系统必须提供驱动程序响应中断
的能力。一般是把一个中断处理程序注册到系统中去。操作系统在硬件中断发生后
调用驱动程序的处理程序。Linux支持中断的共享，即多个设备共享一个中断。
1.2.3 时钟
在实现驱动程序时，很多地方会用到时钟。如某些协议里的超时处理，没有中
断机制的硬件的轮询等。操作系统应为驱动程序提供定时机制。一般是在预定的时
间过了以后回调注册的时钟函数。在网络驱动程序中，如果硬件没有中断功能，定
时器可以提供轮询(poll)方式对硬件进行存取。或者是实现某些协议时需要的超时
重传等。
二.Linux系统网络设备驱动程序
2.1 网络驱动程序的结构
所有的Linux网络驱动程序遵循通用的接口。设计时采用的是面向对象的方法。
一个设备就是一个对象(device 结构)，它内部有自己的数据和方法。每一个设备的
方法被调用时的第一个参数都是这个设备对象本身。这样这个方法就可以存取自身
的数据(类似面向对象程序设计时的this引用)。
一个网络设备最基本的方法有初始化、发送和接收。
------------------- ---------------------
|deliver packets | |receive packets queue|
|(dev_queue_xmit()) | |them(netif_rx()) |
------------------- ---------------------
| | /
/ | |
-------------------------------------------------------
| methods and variables(initialize,open,close,hard_xmit,|
| interrupt handler,config,resources,status...) |
-------------------------------------------------------
| | /
/ | |
----------------- ----------------------
|send to hardware | |receivce from hardware|
----------------- ----------------------
| | /
/ | |
-----------------------------------------------------
| hardware media |
-----------------------------------------------------
初始化程序完成硬件的初始化、device中变量的初始化和系统资源的申请。发送
程序是在驱动程序的上层协议层有数据要发送时自动调用的。一般驱动程序中不对发
送数据进行缓存，而是直接使用硬件的发送功能把数据发送出去。接收数据一般是通
过硬件中断来通知的。在中断处理程序里，把硬件帧信息填入一个skbuff结构中，然
------------------ Linux操作系统网络驱动程序编写 -------------------
------------ Contact the author by mailto:bordi@bordi.dhs.org ------
后调用netif_rx()传递给上层处理。
2.2 网络驱动程序的基本方法
网络设备做为一个对象，提供一些方法供系统访问。正是这些有统一接口的方法，
掩蔽了硬件的具体细节，让系统对各种网络设备的访问都采用统一的形式，做到硬件
无关性。
下面解释最基本的方法。
2.2.1 初始化(initialize)
驱动程序必须有一个初始化方法。在把驱动程序载入系统的时候会调用这个初
始化程序。它做以下几方面的工作。检测设备。在初始化程序里你可以根据硬件的
特征检查硬件是否存在，然后决定是否启动这个驱动程序。配置和初始化硬件。在
初始化程序里你可以完成对硬件资源的配置，比如即插即用的硬件就可以在这个时
候进行配置(Linux内核对PnP功能没有很好的支持，可以在驱动程序里完成这个功
能)。配置或协商好硬件占用的资源以后，就可以向系统申请这些资源。有些资源是
可以和别的设备共享的，如中断。有些是不能共享的，如IO、DMA。接下来你要初始
化device结构中的变量。最后，你可以让硬件正式开始工作。
2.2.2 打开(open)
open这个方法在网络设备驱动程序里是网络设备被激活的时候被调用(即设备状
态由down--up)。所以实际上很多在initialize中的工作可以放到这里来做。比如资
源的申请，硬件的激活。如果dev-open返回非0(error)，则硬件的状态还是down。
open方法另一个作用是如果驱动程序做为一个模块被装入，则要防止模块卸载时
设备处于打开状态。在open方法里要调用MOD_INC_USE_COUNT宏。
2.2.3 关闭(stop)
close方法做和open相反的工作。可以释放某些资源以减少系统负担。close是在
设备状态由up转为down时被调用的。另外如果是做为模块装入的驱动程序，close里
应该调用MOD_DEC_USE_COUNT，减少设备被引用的次数，以使驱动程序可以被卸载。
另外close方法必须返回成功(0==success)。
2.2.4 发送(hard_start_xmit)
所有的网络设备驱动程序都必须有这个发送方法。在系统调用驱动程序的xmit
时，发送的数据放在一个sk_buff结构中。一般的驱动程序把数据传给硬件发出去。
也有一些特殊的设备比如loopback把数据组成一个接收数据再回送给系统，或者
dummy设备直接丢弃数据。
如果发送成功，hard_start_xmit方法里释放sk_buff，返回0(发送成功)。如果
设备暂时无法处理，比如硬件忙，则返回1。这时如果dev-tbusy置为非0，则系统
认为硬件忙，要等到dev-tbusy置0以后才会再次发送。tbusy的置0任务一般由中断
完成。硬件在发送结束后产生中断，这时可以把tbusy置0，然后用mark_bh()调用通
知系统可以再次发送。在发送不成功的情况下，也可以不置dev-tbusy为非0，这样
系统会不断尝试重发。如果hard_start_xmit发送不成功，则不要释放sk_buff。
传送下来的sk_buff中的数据已经包含硬件需要的帧头。所以在发送方法里不需
要再填充硬件帧头，数据可以直接提交给硬件发送。sk_buff是被锁住的(locked)，
确保其他程序不会存取它。
2.2.5 接收(reception)
驱动程序并不存在一个接收方法。有数据收到应该是驱动程序来通知系统的。
一般设备收到数据后都会产生一个中断，在中断处理程序中驱动程序申请一块
sk_buff(skb)，从硬件读出数据放置到申请好的缓冲区里。接下来填充sk_buff中
的一些信息。skb-dev = dev，判断收到帧的协议类型，填入skb-protocol(多协
议的支持)。把指针skb-mac.raw指向硬件数据然后丢弃硬件帧头(skb_pull)。还要
设置skb-pkt_type，标明第二层(链路层)数据类型。可以是以下类型：
PACKET_BROADCAST : 链路层广播
PACKET_MULTICAST : 链路层组播
PACKET_SELF : 发给自己的帧
PACKET_OTHERHOST : 发给别人的帧(监听模式时会有这种帧)
最后调用netif_rx()把数据传送给协议层。netif_rx()里数据放入处理队列然后返
回，真正的处理是在中断返回以后，这样可以减少中断时间。调用netif_rx()以后，
驱动程序就不能再存取数据缓冲区skb。
2.2.6 硬件帧头(hard_header)
硬件一般都会在上层数据发送之前加上自己的硬件帧头，比如以太网(Ethernet)
就有14字节的帧头。这个帧头是加在上层ip、ipx等数据包的前面的。驱动程序提供
一个hard_header方法，协议层(ip、ipx、arp等)在发送数据之前会调用这段程序。
硬件帧头的长度必须填在dev-hard_header_len，这样协议层回在数据之前保留好
硬件帧头的空间。这样hard_header程序只要调用skb_push然后正确填入硬件帧头就
可以了。
在协议层调用hard_header时，传送的参数包括(2.0.xx)：数据的sk_buff，
device指针，protocol，目的地址(daddr)，源地址(saddr)，数据长度(len)。数据
长度不要使用sk_buff中的参数，因为调用hard_header时数据可能还没完全组织好。
saddr是NULL的话是使用缺省地址(default)。daddr是NULL表明协议层不知道硬件目
的地址。如果hard_header完全填好了硬件帧头，则返回添加的字节数。如果硬件帧
头中的信息还不完全(比如daddr为NULL，但是帧头中需要目的硬件地址。典型的情
况是以太网需要地址解析(arp))，则返回负字节数。hard_header返回负数的情况
下，协议层会做进一步的build header的工作。目前Linux系统里就是做arp
(如果hard_header返回正，dev-arp=1，表明不需要做arp，返回负，dev-arp=0，
做arp)。
对hard_header的调用在每个协议层的处理程序里。如ip_output。
2.2.7 地址解析(xarp)
有些网络有硬件地址(比如Ethernet)，并且在发送硬件帧时需要知道目的硬件
地址。这样就需要上层协议地址(ip、ipx)和硬件地址的对应。这个对应是通过地址
解析完成的。需要做arp的的设备在发送之前会调用驱动程序的rebuild_header方
法。调用的主要参数包括指向硬件帧头的指针，协议层地址。如果驱动程序能够解
析硬件地址，就返回1，如果不能，返回0。
对rebuild_header的调用在net/core/dev.c的do_dev_queue_xmit()里。
2.2.8 参数设置和统计数据
在驱动程序里还提供一些方法供系统对设备的参数进行设置和读取信息。一般
只有超级用户(root)权限才能对设备参数进行设置。设置方法有：
dev-set_mac_address()
当用户调用ioctl类型为SIOCSIFHWADDR时是要设置这个设备的mac地址。一般
对mac地址的设置没有太大意义的。
dev-set_config()
------------------ Linux操作系统网络驱动程序编写 -------------------
------------ Contact the author by mailto:bordi@bordi.dhs.org ------
当用户调用ioctl时类型为SIOCSIFMAP时，系统会调用驱动程序的set_config
方法。用户会传递一个ifmap结构包含需要的I/O、中断等参数。
dev-do_ioctl()
如果用户调用ioctl时类型在SIOCDEVPRIVATE和SIOCDEVPRIVATE+15之间，系统
会调用驱动程序的这个方法。一般是设置设备的专用数据。
读取信息也是通过ioctl调用进行。除次之外驱动程序还可以提供一个
dev-get_stats方法，返回一个enet_statistics结构，包含发送接收的统计信息。
ioctl的处理在net/core/dev.c的dev_ioctl()和dev_ifsioc()里。
驱动开发的步骤有哪些
步骤？没有什么现成的可作为规律来用的步骤。
开发驱动主要有两方面的基础要求：
a，明白你手头的硬件工作原理，包括处理器架构的知识，还有外设控制器的 datasheet 为必读之物；
b，假如你们要开发的整个系统是裸机程序，那你要开发的驱动程序就是一套和硬件打交道的函数库；但是假如你们计划在产品中使用一个操作系统，那开发驱动之前就需要熟悉这个操作系统的相关内部操作原理，因为你写的是驱动程序需要很好的“镶嵌”到这个操作系统的环境中去。
具体的，可以参考 JulianTec 的这篇文章：《应用程序，操作系统，驱动程序和硬件》
如何编写驱动程序？
如何编写Linux设备驱动程序
回想学习Linux操作系统已经有近一年的时间了，前前后后，零零碎碎的一路学习过来，也该试着写的东西了。也算是给自己能留下一点记忆和回忆吧！由于完全是自学的，以下内容若有不当之处，还请大家多指教。
Linux是Unix操作系统的一种变种，在Linux下编写驱动程序的原理和思想完全类似于其他的Unix系统，但它dos或window环境下的驱动程序有很大的区别。在Linux环境下设计驱动程序，思想简洁，操作方便，功能也很强大，但是支持函数少，只能依赖kernel中的函数，有些常用的操作要自己来编写，而且调试也不方便。
以下的一些文字主要来源于khg，johnsonm的Write linux device driver，Brennan's Guide to Inline Assembly，The Linux A-Z，还有清华BBS上的有关device driver的一些资料。
一、Linux device driver 的概念
系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件的细节，这样在应用程序看来，硬件设备只是一个设备文件，应用程序可以象操作普通文件一样对硬件设备进行操作。设备驱动程序是内核的一部分，它完成以下的功能:
1、对设备初始化和释放。
2、把数据从内核传送到硬件和从硬件读取数据。
3、读取应用程序传送给设备文件的数据和回送应用程序请求的数据。
4、检测和处理设备出现的错误。
在Linux操作系统下有三类主要的设备文件类型，一是字符设备，二是块设备，三是网络设备。字符设备和块设备的主要区别是:在对字符设备发出读/写请求时，实际的硬件I/O一般就紧接着发生了，块设备则不然，它利用一块系统内存作缓冲区，当用户进程对设备请求能满足用户的要求，就返回请求的数据，如果不能，就调用请求函数来进行实际的I/O操作。块设备是主要针对磁盘等慢速设备设计的，以免耗费过多的CPU时间来等待。
已经提到，用户进程是通过设备文件来与实际的硬件打交道。每个设备文件都都有其文件属性(c/b)，表示是字符设备还是块设备?另外每个文件都有两个设备号，第一个是主设备号，标识驱动程序，第二个是从设备号，标识使用同一个设备驱动程序的不同的硬件设备，比如有两个软盘，就可以用从设备号来区分他们。设备文件的的主设备号必须与设备驱动程序在登记时申请的主设备号一致，否则用户进程将无法访问到驱动程序。
最后必须提到的是，在用户进程调用驱动程序时，系统进入核心态，这时不再是抢先式调度。也就是说，系统必须在你的驱动程序的子函数返回后才能进行其他的工作。如果你的驱动程序陷入死循环，不幸的是你只有重新启动机器了，然后就是漫长的fsck。
读/写时，它首先察看缓冲区的内容，如果缓冲区的数据未被处理，则先处理其中的内容。
如何编写Linux操作系统下的设备驱动程序
二、实例剖析
我们来写一个最简单的字符设备驱动程序。虽然它什么也不做，但是通过它可以了解Linux的设备驱动程序的工作原理。把下面的C代码输入机器，你就会获得一个真正的设备驱动程序。
#define __NO_VERSION__
#include modules.h
#include version.h
char kernel_version [] = UTS_RELEASE;
这一段定义了一些版本信息，虽然用处不是很大，但也必不可少。Johnsonm说所有的驱动程序的开头都要包含config.h，一般来讲最好使用。
由于用户进程是通过设备文件同硬件打交道，对设备文件的操作方式不外乎就是一些系统调用，如 open，read，write，close…， 注意，不是fopen， fread，但是如何把系统调用和驱动程序关联起来呢?这需要了解一个非常关键的数据结构：
struct file_operations
{
int (*seek) (struct inode * ，struct file *， off_t ，int);
int (*read) (struct inode * ，struct file *， char ，int);
int (*write) (struct inode * ，struct file *， off_t ，int);
int (*readdir) (struct inode * ，struct file *， struct dirent * ，int);
int (*select) (struct inode * ，struct file *， int ，select_table *);
int (*ioctl) (struct inode * ，struct file *， unsined int ，unsigned long);
int (*mmap) (struct inode * ，struct file *， struct vm_area_struct *);
int (*open) (struct inode * ，struct file *);
int (*release) (struct inode * ，struct file *);
int (*fsync) (struct inode * ，struct file *);
int (*fasync) (struct inode * ，struct file *，int);
int (*check_media_change) (struct inode * ，struct file *);
int (*revalidate) (dev_t dev);
}
这个结构的每一个成员的名字都对应着一个系统调用。用户进程利用系统调用在对设备文件进行诸如read/write操作时，系统调用通过设备文件的主设备号找到相应的设备驱动程序，然后读取这个数据结构相应的函数指针，接着把控制权交给该函数。这是linux的设备驱动程序工作的基本原理。既然是这样，则编写设备驱动程序的主要工作就是编写子函数，并填充file_operations的各个域。
下面就开始写子程序。
#include types.h
#include fs.h
#include mm.h
#includeconfig.h
#include errno.h
#include segment.h
unsigned int test_major = 0;
static int read_test(struct inode *node，struct file *file，char *buf，int count)
{
int left;
if (verify_area(VERIFY_WRITE，buf，count) == -EFAULT )
return -EFAULT;
for(left = count ; left 0 ; left--)
{
__put_user(1，buf，1);
buf++;
}
return count;
}
这个函数是为read调用准备的。当调用read时，read_test()被调用，它把用户的缓冲区全部写1。buf 是read调用的一个参数。它是用户进程空间的一个地址。但是在read_test被调用时，系统进入核心态。所以不能使用buf这个地址，必须用__put_user()，这是kernel提供的一个函数，用于向用户传送数据。另外还有很多类似功能的函数。请参考Robert著的《Linux内核设计与实现》（第二版）。然而，在向用户空间拷贝数据之前，必须验证buf是否可用。这就用到函数verify_area。
static int write_tibet(struct inode *inode，struct file *file，const char *buf，int count)
{
return count;
}
static int open_tibet(struct inode *inode，struct file *file )
{
MOD_INC_USE_COUNT;
return 0;
}
static void release_tibet(struct inode *inode，struct file *file )
{
MOD_DEC_USE_COUNT;
}
这几个函数都是空操作。实际调用发生时什么也不做，他们仅仅为下面的结构提供函数指针。
struct file_operations test_fops = {
NULL，
read_test，
write_test，
NULL， /* test_readdir */
NULL，
NULL， /* test_ioctl */
NULL， /* test_mmap */
open_test，
release_test，
NULL， /* test_fsync */
NULL， /* test_fasync */
/* nothing more， fill with NULLs */
};
这样，设备驱动程序的主体可以说是写好了。现在要把驱动程序嵌入内核。驱动程序可以按照两种方式编译。一种是编译进kernel，另一种是编译成模块(modules)，如果编译进内核的话，会增加内核的大小，还要改动内核的源文件，而且不能动态的卸载，不利于调试，所以推荐使用模块方式。
int init_module(void)
{
int result;
result = register_chrdev(0， "test"， test_fops);
if (result 0) {
printk(KERN_INFO "test: can't get major number\n");
return result;
}
if (test_major == 0) test_major = result; /* dynamic */
return 0;
}
在用insmod命令将编译好的模块调入内存时，init_module 函数被调用。在这里，init_module只做了一件事，就是向系统的字符设备表登记了一个字符设备。register_chrdev需要三个参数，参数一是希望获得的设备号，如果是零的话，系统将选择一个没有被占用的设备号返回。参数二是设备文件名，参数三用来登记驱动程序实际执行操作的函数的指针。
如果登记成功，返回设备的主设备号，不成功，返回一个负值。
void cleanup_module(void)
{
unregister_chrdev(test_major，"test");
}
在用rmmod卸载模块时，cleanup_module函数被调用，它释放字符设备test在系统字符设备表中占有的表项。
一个极其简单的字符设备可以说写好了，文件名就叫test.c吧。
下面编译 :
$ gcc -O2 -DMODULE -D__KERNEL__ -c test.c
得到文件test.o就是一个设备驱动程序。
如果设备驱动程序有多个文件，把每个文件按上面的命令行编译，然后
ld -r file1.o file2.o -o modulename。
驱动程序已经编译好了，现在把它安装到系统中去。
$ insmod –f test.o
如果安装成功，在/proc/devices文件中就可以看到设备test，并可以看到它的主设备号。要卸载的话，运行 :
$ rmmod test
下一步要创建设备文件。
mknod /dev/test c major minor
c 是指字符设备，major是主设备号，就是在/proc/devices里看到的。
用shell命令
$ cat /proc/devices
就可以获得主设备号，可以把上面的命令行加入你的shell script中去。
minor是从设备号，设置成0就可以了。
我们现在可以通过设备文件来访问我们的驱动程序。写一个小小的测试程序。
#include
#include types.h
#include stat.h
#include
main()
{
int testdev;
int i;
char buf[10];
testdev = open("/dev/test"，O_RDWR);
if ( testdev == -1 )
{
printf("Cann't open file \n");
exit(0);
}
read(testdev，buf，10);
for (i = 0; i 10;i++)
printf("%d\n"，buf[i]);
close(testdev);
}
编译运行，看看是不是打印出全1 ？
以上只是一个简单的演示。真正实用的驱动程序要复杂的多，要处理如中断，DMA，I/O port等问题。这些才是真正的难点。请看下节，实际情况的处理。
如何编写Linux操作系统下的设备驱动程序
三、设备驱动程序中的一些具体问题
1。 I/O Port。
和硬件打交道离不开I/O Port，老的ISA设备经常是占用实际的I/O端口，在linux下，操作系统没有对I/O口屏蔽，也就是说，任何驱动程序都可对任意的I/O口操作，这样就很容易引起混乱。每个驱动程序应该自己避免误用端口。
有两个重要的kernel函数可以保证驱动程序做到这一点。
1）check_region(int io_port， int off_set)
这个函数察看系统的I/O表，看是否有别的驱动程序占用某一段I/O口。
参数1：I/O端口的基地址，
参数2：I/O端口占用的范围。
返回值：0 没有占用， 非0，已经被占用。
2）request_region(int io_port， int off_set，char *devname)
如果这段I/O端口没有被占用，在我们的驱动程序中就可以使用它。在使用之前，必须向系统登记，以防止被其他程序占用。登记后，在/proc/ioports文件中可以看到你登记的I/O口。
参数1：io端口的基地址。
参数2：io端口占用的范围。
参数3：使用这段io地址的设备名。
在对I/O口登记后，就可以放心地用inb()， outb()之类的函来访问了。
在一些pci设备中，I/O端口被映射到一段内存中去，要访问这些端口就相当于访问一段内存。经常性的，我们要获得一块内存的物理地址。
2。内存操作
在设备驱动程序中动态开辟内存，不是用malloc，而是kmalloc，或者用get_free_pages直接申请页。释放内存用的是kfree，或free_pages。 请注意，kmalloc等函数返回的是物理地址！
注意，kmalloc最大只能开辟128k-16，16个字节是被页描述符结构占用了。
内存映射的I/O口，寄存器或者是硬件设备的RAM(如显存)一般占用F0000000以上的地址空间。在驱动程序中不能直接访问，要通过kernel函数vremap获得重新映射以后的地址。
另外，很多硬件需要一块比较大的连续内存用作DMA传送。这块程序需要一直驻留在内存，不能被交换到文件中去。但是kmalloc最多只能开辟128k的内存。
这可以通过牺牲一些系统内存的方法来解决。
3。中断处理
同处理I/O端口一样，要使用一个中断，必须先向系统登记。
int request_irq(unsigned int irq ，void(*handle)(int，void *，struct pt_regs *)，
unsigned int long flags， const char *device);
irq: 是要申请的中断。
handle：中断处理函数指针。
flags：SA_INTERRUPT 请求一个快速中断，0 正常中断。
device：设备名。
如果登记成功，返回0，这时在/proc/interrupts文件中可以看你请求的中断。
4。一些常见的问题。
对硬件操作，有时时序很重要（关于时序的具体问题就要参考具体的设备芯片手册啦！比如网卡芯片RTL8139）。但是如果用C语言写一些低级的硬件操作的话，gcc往往会对你的程序进行优化，这样时序会发生错误。如果用汇编写呢，gcc同样会对汇编代码进行优化，除非用volatile关键字修饰。最保险的办法是禁止优化。这当然只能对一部分你自己编写的代码。如果对所有的代码都不优化，你会发现驱动程序根本无法装载。这是因为在编译驱动程序时要用到gcc的一些扩展特性，而这些扩展特性必须在加了优化选项之后才能体现出来。
写在后面：学习Linux确实不是一件容易的事情，因为要付出很多精力，也必须具备很好的C语言基础；但是，学习Linux也是一件非常有趣的事情，它里面包含了许多高手的智慧和“幽默”，这些都需要自己亲自动手才能体会到，O(∩_∩)O~哈哈！