NDIS驱动框架探究..docVIP

NDIS驱动框架探究 By AntBean Fearless，Passion， Endure 在我看来NDIS驱动有几个难点：1.框架难，NDIS驱动的整体框架跟接触的文件过滤驱动很不一样，你需要考虑的比较多，整个框架的堆叠不再是向文件过滤驱动那样，使用AttachDevice堆叠设备，然后IoCallDriver传递请求；2.硬件操作的敏感性，网卡设备的热插拔，电源状态的变化都会影响到驱动程序；3.系统资源使用的敏感性，NDIS驱动本身是要收包 发包，网络包的数据量是非常大的，如果在分配网络封包时没有及时释放，很有可能导致系统资源不足。本篇文章主要对NDIS驱动框架进行探究。 在介绍内容之前，先说明一些概念。 面向连接的网络和无连接的网络 与 面向连接的协议和无连接的协议 面向连接的网络是指通过电路交换进行的局域网。一台机器如果需要给另外一台机器发送信息，就需要先像打电话一样呼叫另外一台机器，另外一台机器可以接受或者拒绝。一旦接受，就会使用一个专用的线路维持该连接。该连接的容量是固定的，而且只归该连接所有。 这种局域网最典型的例子是ATM网络。 无连接的网络是指通过分组交换传输信息的局域网。一台机器如果给另外一台机器发送信息，需要传输的数据组织成一个分组，发送出去。所有正在通信的计算机共用一个连接。典型的例子是以太网和FDDI。 (参见《用TCP/IP进行网际互联 第四版》第一卷 第二章 底层网络技术回顾) 以上的面向连接和无连接针对的是物理上的网络硬件，属于OSI七层模型中的物理层；而面向连接的协议和无连接的协议则是针对协议的，与硬件是无关的，属于协议层。常见的面向连接的协议有TCP协议，无连接的协议有UDP协议。 2. 电源状态 D0 D1 D2 D3 ACPI规定，设备处于四种状态之一，D0到D3。D0是完全打开，D3是完全关闭。D1和D2由驱动程序自己定义。 （参见《深入解析windows操作系统 第四版》 第九章 第五小节 电源管理器） 序列化NDIS驱动和非序列化NDIS驱动 对NDIS驱动的请求不再是IRP的形式，而是Packet的形式。其他驱动例如TDI驱动通过NDIS库函数如NdisSend向NDIS驱动发送请求，事实上NDIS库会对Packet进行排队，保证对NDIS驱动的调用是串行的，一个Packet处理完才会发送另一个Packet给NDIS驱动。 这样的NDIS驱动就叫做序列化的NDIS驱动。 而一个非序列化的NDIS驱动则是指，NDIS库不负责对Packet进行排队和串行化，需要NDIS驱动自己处理同时多个Packet请求的情形。排队和管理多个并发请求的任务落到了NDIS驱动程序的头上。 （参见《深入解析windows操作系统 第四版》 第十三章 第六小节 NDIS驱动程序） NDIS驱动本身分为两种，Protocol Driver和Miniport Driver。至于NDIS中间层驱动，则是由前两种演化而来。Miniport Driver用来驱动网卡，Protocol Driver是协议驱动，负责将要发送的数据组装成符合特定Protocol的网络封包然后调用Miniport Driver提供的发送功能完成发送。也就是说，Protocol Driver和Miniport Driver具有实质意义上的堆叠关系。Protocol Driver负责网络数据的封包，以及封包的解析获得；而Miniport Driver负责提供物理硬件上的驱动，保证数据包能够正常收发，并通知上层的Protocol Driver。 Miniport Driver和Protocol Driver并不是通过普通意义上的IoAttachDevice进行叠加的。而是通过NDIS库进行粘合的。NDIS库要求Miniport Driver和Protocol Driver各自提供符合NDIS要求的接口，供NDIS库在运行时调用。这个过程类似于C++中的虚函数。NDIS库要求这Protocol Driver和Miniport Driver各自实现自己那个类的虚函数，而NDIS库自己则是直接调用这些虚函数去完成操作。 下面照样是用具体的代码说事儿。我将使用ReactOS上面的代码来分析NDIS驱动和NDIS库之间的关系。当然，主要参考了毛德操老师的《windows内核情景分析》和ReactOS 0.3.1的代码。下面如无特殊说明，windows内核均指ReactOS的代码，代码均摘自ReactOS 0.3.1。 必须先声明的是，我不会试图去分析NDIS驱动框架的各个方面。我将只针对NDIS驱动的初始化和NDIS驱动接收包 发送包的流程来说明NDIS库和NDIS驱动的关系。