网络驱动应用开发 --续四

       

 

      

       这段时间太忙拉，工作上的事情，都没有来得及整理一些网络驱动开发方面东西。希望大家能体谅。

       前面把Windows系统的体系，驱动类型做了个简单的介绍，对于实际开发驱动是远远不够的。里边还有很多细节，比如操作系统基础，多任务处理，等很多东西都是非常重要的，他们都是为驱动开发做下一个好的铺垫的。没有基础的掌握，对于后面的开发，没有一个好的理论指导。在此我把自己学习参考的资料推荐给大家。

       1   WindowsWDM设备驱动程序开发指南.pdf（电子版）

       2   Windows环境下的设备驱动程序设计.pdf（电子版）

       3   Windows.2000_XP.WDM设备驱动程序开发.pdf（电子版）

       4   TCP.IP路由技术卷一中文版.pdf（电子版）

       5   TCP.IP路由技术卷二中文版.pdf（电子版）

       6   TCP IP Illustrated, Volume 1 The Protocols [Addison Wesley 93].chm

       7   英文原版计算机信息技术图书].12.Cisco.Press.TCP.IP.First.Step.Dec.2004.eBook-LiB.chm（电子版）

       8   C程序设计_谭浩强.pdf（电子版）

       9   TCP_IP_Architecture_Protocols_and_Implementation_With_IPv6_and_IP_Security--McGraw_Hill_Series_On_Computer_Communications.chm（电子版）

      10   Tcp-Ip Routing - Mcgraw Hill..Pdf（电子版）

      11    Programming TCP-IP with Sockets.pdf（电子版）

      12   ip协议在数据链路层封装携带.pdf（电子版）

      13   Windows网络编程

……

……

……

       这些书籍大部分都能在网上下载下来，有的是通过Emule下的。其他的资料自己需要那方面的都可以找来参考。对于TCP/IP协议部分，我们可以参考RFC文档。里边有比较详细的描述。

      下面我们继续对Windows驱动做探讨。其中涉及到很多应用部分，因为时间上的原因，我就不在此翻译了，直接应用原文。由于我们需要开发的网络方面的驱动应用，它并不是真正的网卡级（硬件）驱动，它只是过滤驱动中间程驱动。但是它必须符合WDM驱动的一些特性。因为自从Windows98极其以后的系统，都具有PNP特性。所以驱动也在发生一些改变。

        

以下是关于WDM驱动的介绍：

      To allow driver developers to write device drivers that are source-code compatible across all Microsoft® Windows® operating systems, the Windows Driver Model (WDM) was introduced. Kernel-mode drivers that follow WDM rules are called WDM drivers. All WDM drivers must:

Include wdm.h, not ntddk.h. (Note that wdm.h is a subset of ntddk.h.)

Be designed as a bus driver, a function driver, or a filter driver, as described in Types of WDM Drivers.

Create device objects as described in WDM Device Objects and Device Stacks.

Support Plug and Play.

Support Power Management.

Support Windows Management Instrumentation (WMI)

Does this DDK Cover non-WDM Drivers?

While this DDK emphasizes development of WDM drivers for kernel mode, information pertinent to kernel-mode drivers that do not follow WDM rules is also provided when necessary. This allows you to maintain existing non-WDM drivers and to write new drivers that interface with these existing drivers.

Should You Always Write a WDM Driver?

If you are writing new kernel-mode drivers, they should be WDM drivers unless you are writing a driver that will be inserted into a stack of non-WDM drivers. Please read the documentation for device type-specific Microsoft-supplied drivers, contained in this DDK documentation, to determine how new drivers must interface with Microsoft-supplied drivers.

Note  All new driver stacks should consist of WDM drivers.

There are cross-platform issues to consider, whether you are developing WDM or non-WDM drivers. For more information, see Writing Drivers for Multiple Platforms and Operating Systems.

    Types of WDM Drivers

There are three kinds of WDM drivers:

      Bus drivers, which drive an I/O bus and provide per-slot functionality that is device-independent.

      Function drivers, which drive an individual device.

      Filter drivers, which filter I/O requests for a device, a class of devices, or a bus.

In this context, a bus is any device to which other physical, logical, or virtual devices are attached; a bus includes traditional buses such as SCSI and PCI, as well as parallel ports, serial ports, and i8042 ports.

It is important for driver writers to understand the different kinds of WDM drivers and to know which kind of driver they are writing. For example, whether or not a driver handles each Plug and Play IRP and how to handle such IRPs depends on what kind of driver is being written (bus driver, function driver, or filter driver).

       The following figure shows the relationship between the bus driver, function driver, and filter drivers for a device.

      

       

Possible Driver Layers

       Each device typically has a bus driver for the parent I/O bus, a function driver for the device, and zero or more filter drivers for the device. A driver design that requires many filter drivers does not yield optimal performance.

       The drivers in the previous figure are the following:

A bus driver services a bus controller, adapter, or bridge. Bus drivers are required drivers; there is one bus driver for each type of bus on a machine. Microsoft provides bus drivers for most common buses. IHVs and OEMs can provide other bus drivers.

       A bus filter driver typically adds value to a bus and is supplied by Microsoft or a system OEM. There can be any number of bus filter drivers for a bus.

Lower-level filter drivers typically modify the behavior of device hardware. They are optional and are typically supplied by IHVs. There can be any number of lower-level filter drivers for a device.

A function driver is the main driver for a device. A function driver is typically written by the device vendor and is required (unless the device is being used in raw mode).

Upper-level filter drivers typically provide added-value features for a device. They are optional and are typically provided by IHVs.

         以上简要的描述了windows　WDM驱动的类型,可以看出WDM是分层驱动，采用分层的模型，与TCP/IP协议的分层思想入出一则。层间采用接口方式调用。

以下介绍bus drivers, function drivers, filter drivers的功能。

Bus Drivers：

A bus driver services a bus controller, adapter, or bridge (see the Possible Driver Layers figure). Microsoft provides bus drivers for most common buses, such as PCI, PnpISA, SCSI, and USB. Other bus drivers can be provided by IHVs or OEMs. Bus drivers are required drivers; there is one bus driver for each type of bus on a machine. A bus driver can service more than one bus if there is more than one bus of the same type on the machine.

The primary responsibilities of a bus driver are to:

Enumerate the devices on its bus.

Respond to Plug and Play IRPs and power management IRPs.

Multiplex access to the bus (for some buses).

Generically administer the devices on its bus.

During enumeration, a bus driver identifies the devices on its bus and creates device objects for them. (For information about device objects, see Device Objects and Device Stacks.) The method a bus driver uses to identify connected devices depends on the particular bus.

A bus driver performs certain operations on behalf of the devices on its bus, including accessing device registers to physically change the power state of a device. For example, when the device goes to sleep, the bus driver sets device registers to put the device in the proper device power state.

Note, however, that a bus driver does not handle read and write requests for the devices on its bus. Read and write requests to a device are handled by the device's function driver. Only if the device is being used in raw mode does the parent bus driver handle reads and writes for the device.

A bus driver acts as the function driver for its controller, adapter, or bridge, and therefore manages device power policy for these components.

A bus driver can be implemented as a driver/minidriver pair, the way a SCSI port/miniport driver pair drives a SCSI host bus adapter (HBA). In such driver pairs, the minidriver is linked to the second driver, which is a DLL.

Function Drivers：

A function driver is the main driver for a device (see the Possible Driver Layers figure). A function driver is typically written by the device vendor and is required (unless the device is being used in raw mode). The PnP Manager loads at most one function driver for a device. A function driver can service one or more devices.

A function driver provides the operational interface for its device. Typically the function driver handles reads and writes to the device and manages device power policy.

The function driver for a device can be implemented as a driver/minidriver pair, such as a port/miniport driver pair or a class/miniclass driver pair. In such driver pairs, the minidriver is linked to the second driver, which is a DLL.

If a device is being driven in raw mode, it has no function driver and no upper or lower-level filter drivers. All raw-mode I/O is done by the bus driver and optional bus filter drivers.

Filter Drivers

Filter drivers are optional drivers that add value to or modify the behavior of a device. A filter driver can service one or more devices.

Bus Filter Drivers：

Bus filter drivers typically add value to a bus and are supplied by Microsoft or a system OEM (see the Possible Driver Layers figure). Bus filter drivers are optional. There can be any number of bus filter drivers for a bus.

A bus filter driver could, for example, implement proprietary enhancements to standard bus hardware.

For devices described by an ACPI BIOS, the Power Manager inserts a Microsoft-supplied ACPI filter (bus filter driver) above the bus driver for each such device. The ACPI filter carries out device power policy and powers on and off devices. The ACPI filter is transparent to other drivers and is not present on non-ACPI machines.

Lower-Level Filter Drivers：

Lower-level filter drivers typically modify the behavior of device hardware (see the Possible Driver Layers figure). They are typically supplied by IHVs and are optional. There can be any number of lower-level filter drivers for a device.

A lower-level device filter driver monitors and/or modifies I/O requests to a particular device. Typically, such filters redefine hardware behavior to match expected specifications.

A lower-level class filter driver monitors and/or modifies I/O requests for a class of devices. For example, a lower-level class filter driver for mouse devices could provide acceleration, performing a nonlinear conversion of mouse movement data.

Upper-Level Filter Drivers：

Upper-level filter drivers typically provide added-value features for a device (see the Possible Driver Layers figure). Such drivers are usually provided by IHVs and are optional. There can be any number of upper-level filter drivers for a device.

An upper-level device filter driver adds value for a particular device. For example, an upper-level device filter driver for a keyboard could enforce additional security checks. 

       An upper-level class filter driver adds value for all devices of a particular class.

       以上介绍了Bus Drivers,Filter Drivers,Function Driver他们的各层关系极其作用。通过了解他们，可以确定我们自己要编写的驱动属于什么类型的。今天我们就到此结束吧。由于时间上的关系，忘大家能体谅。