【转帖】passthru的说明书！！！

1) During DriverEntry, the Passthru driver registers as a protocol and an Intermediate miniport driver. 

1)在DriverEntry（驱动进入点，相当于动态链接库的DllMain）模块，passthru驱动将向系统注册一个protocol（协议）和一个intermedia miniport（中间层微[小]端口）驱动接口，既向上层的TDI（或叫做协议[传输]层）提供miniport接口，向下的真正面对物理连接的网络驱动层miniport层，提供protocol接口（到不如说是提供接口来继承NIC/WAN miniport）。

2) Later on, Ndis calls the Passthru protocol to bind to a physical adapter.
2）然后passthru将绑定到一个真正的物理的网卡上！就是过去常说的，在网上邻居的属性里常用的那种绑定。

3) In the context of BindAdapterHandler and after opening of the underlying physical adapter succeeds, the Passthru driver queries the reserved keyword "UpperBindings" to get a list of device names for the virtual adapters that this particular binding is to expose.
3）在BindAdapterHandler（绑定一个指向适配器的句柄指针）的关系表的之中，以及成功的打开下层的物理适配器的时候，passthru驱动通过访问保留关键字“UpperBindings”来取得详细的绑定向虚拟适配器的设备名列表。

4) For each device name, the Passthru driver calls NdisIMInitializeDeviceInstance.
4）得到设备名后，passthru驱动将调用NdisIMInitializeDeviceInstance（就是NDIS中间层设备驱动miniport初始化函数），调用来做什么用？当然是设置一个虚拟网络界面卡的I/O操作给已经绑底下层NIC驱动的中间层驱动（IM driver），并返回NDIS_STATUS类型的值通知执行结果。

5) In response, Ndis will call back Passthru miniport InitializeHandler entry point.
5）作为回应，NDIS将返回passthru的微端口初始化句柄的函数进入点。

6) After InitializeHandler successfully returns, ndis will take care of getting upper-layer protocols to bind to these newly created virtual adapters.
6）当初始化句柄成功返回的时候，NDIS把上层协议接口绑定到一个虚拟适配器，

7) All requests and sends coming from upper-layer protocols for the Passthru miniport driver are repackaged and sent down to ndis, to be passed to the physical adapter.
7）所有来自上层协议接口的请求和发送passthr驱动会把他们从新打包并向下发送到NDIS，使它们能够传送到物理的适配器。

8) All indications coming from bindings to the physical adapters are sent up as if they belong to virtual adapters.
8）所有的来自物理适配器的指示会向上发送到它们能够适用的虚拟适配器。

9) When Ndis asks the Passthru driver to close the binding between a physical adapter and Passthru protocol, the Passthru driver first calls NdisIMDeInitializeDeviceInstance for the virtual adapter representing that particular binding.
9）当NDIS通知passthru驱动将要关闭一个passthr协议接口与物理适配器之间的绑定的时候，passthru驱动会先调用NdisIMDeInitializeDeviceInstance 给虚拟适配器另一个明确的绑定。

10) Ndis in turn will close all the bindings between upper-layer protocols and virtual Passthru adapter.
10）NDIS关闭的时候也回关闭所有上层协议接口和虚拟适配器之间的绑定。

11) After all the bindings are closed, Ndis will call HaltHandler entry point in Passthru driver for the virtual adapter and returns back from NdisIMDeInitializeDeviceInstance.
11）当所有的绑定都已经关闭的时候，NDIS调用passthru的崩溃句柄（HaltHandler）进入点，并从NdisIMDeInitializeDeviceInstance函数中返回。

12) The Passthru protocol then closes the binding to the physical adapter and completes the unbind request issued in step 9.
12）passthru 协议关闭物理适配器的绑定，关于完成反绑定请求的方法已经在第9步里发布。

13) To add Power Management Capabilities
13）添加电源管理兼容性。


13.1 During initialization, the Passthru miniport should set the Attribute 'NDIS_ATTRIBUTE_NO_HALT_ON_SUSPEND' during the miniport initialization.
13.1）初始化的过程中，passthru微端口初始化过程回设置“NDIS_ATTRIBUTE_NO_HALT_ON_SUSPEND”属性。

13.2 When the Passthru miniport is requested to report its Plug and Play capabilities (OID_PNP_CAPABILITIES), the Passthru miniport must pass the request to the miniport below the Passthru protocol. If this request succeeds, then the Passthru miniport should return this buffer with a status of NDIS_STATUS_SUCCESS:
13.3）当passthru请求报告它的即插既用兼容性(OID_PNP_CAPABILITIES)的时候，passthru微端口必须通过passthru向下层协议接口传送请求，如果这个请求能成功，passthru将会返回保存NDIS_STATUS_SUCCESS状态的缓存。

NDIS_DEVICE_POWER_STATE MinMagicPacketWakeUp = NdisDeviceStateUnspecified;
NDIS设备电源状态 唤醒小魔术包 NDIS设备状态未定义

NDIS_DEVICE_POWER_STATE MinPatternWakeUp = NdisDeviceStateUnspecified;
NDIS设备电源状态 小型唤醒 NDIS设备状态未定义

NDIS_DEVICE_POWER_STATE MinLinkChangeWakeUp = NdisDeviceStateUnspecified
NDIS设备电源状态 小连接唤醒 NDIS设备状态未定义

If the miniport below the Passthru protocol fails this request, then the status that was returned should be used to respond to the original request that was made to the Passthru miniport.
如果微端口不能成功完成请求，那就返回建立了的passthru微端口的标准请求状态。

13.3 The OID_PNP_SET_POWER and OID_PNP_QUERY_POWER should not be passed to the miniport below the Passthru protocol, as those miniports will receive independent requests from ndis.
13.3）passthru的协议接口将不会收到OID_PNP_SET_POWER和OID_PNP_QUERY_POWER消息，这些微端口将收到来自NDIS的要求定义/声明的请求。

13.4 When the Passthru is asked to go to standby, it should use the Passthru protocol's PnP Handler to block all new sends and requests, and wait for all outstanding sends and requests to complete. This should be done before returning from the PnP Handler.
13.4）当passthru已经要求转换到待命状态时，passthru协议接口会使用PnP句柄来拦截所有新的发送和请求，并等待所有非待命的发送和请求的完成，这些都会在返回PnP句柄的时候结束。


14) To Add LBFO (Load Balancing & Fail Over)
添加LBFO（装载负载平衡和容错处理）

Goal: To add load-balancing capabilities to the Passthru driver. TCP/IP should see only one network card connected to it. This is the primary miniport. The second card is the secondary miniport of this primary miniport. All receives are performed by the primary miniport and all sends are done by the secondary miniport. All sends and related requests are passed to the secondary miniport.
目的：为passthru添加了负载平衡兼容性后，TCP/1P堆栈将只能见到一个网卡与它连接，这就是主微端口。第二块网卡变成了主微端口的辅助端口，所有的接收任务由主微端口执行，那么所有的发送任务就将由辅助微端口来完成。所有的发送和释放任务将移交给辅助微端口来完成。

14.1 During miniport initialization, the new Passthru miniport searches through the list of existing Passthru miniport instantiations to see if a miniport with the same bundle identifier exists. If so, it calls NdisMSetMiniportSecondary on the two structures. The already instantiated Passthru miniport is the primary miniport.
14.1在微端口初始化的时候，passthru微端口会在列表中查找所有存在的passthru微端口初始化并从中得到相同的微端口的绑定声明，如果有，它会分别在两个结构体中分别调用NdisMSetMiniportSecondary（设置辅助微端口）函数，即时完成的passthru微端口是主端口。

14.2 During run time all sends are routed to the secondary miniport, and all receives are sent to the primary miniport.
14.2）在运行的过程中所有的发送任务会被路由到辅助微端口，所有的接收任务发送到主端口。

14.3 All requests, sends, and receives should be completed on the handles that these actions were initiated on.
14.3）所有的请求、发送和接收任务将由他们初始化中的句秉来完成。

14.4 All requests should be passed on to the miniport below the Passthru miniport that they were requested on.
14.4）所有的请求会传送给它们所请求的passthru微端口。

Note: There is an exception to above rule : some requests to the primary Passthru miniport may be redirected to the secondary miniport. In such a case, when the request needs to be completed, it should use the handles present in the primary miniport's data structure.
注意：这些是违反规则的例外：有一些请求向主passthru主微端口请求有可能会被从定向到辅助微端口，在这个案例中，当一个请求需要被完成的时候，它必须使用主微端口的数据结构来提供句柄。

14.5 The user can change the bundle ID at run time. A NetEventReconfigure, with the new bundleID, is sent to the Passthru protocol's Protocol PnP Handler when this happens.
14.5）用户可以在运行当中改变捆绑ID，一个网络事件从配置，将会新建捆绑ID，并会在它发生的时候发送到passthru 协议接口的协议PnP句柄！

14.6 When the Passthru is reconfigured, it leaves the bundle that it is part of and could join a new bundle. Salient points follow.
14.6）当passthru被从新配置的后，他将离开原先的捆绑并加入到新的捆绑当中！跟着就突出指针？？这不知道该怎么翻译~~

14.7 To activate LBFO, ensure that '#ifdef __LBFO' is a valid statement (not commented out) in Passthru.h. Only when __LBFO is defined will the Passthru driver call the NdisMSetMiniportSecondary API.
14.7 要激活LBFO（负载平衡与容错处理），必须确认“ifdef __LBFO”声明在passthru.h中存在（千万别注释掉！！！）！！！只有在__LBFO被定义了，passthru驱动才回调用NdisMSetMiniportSecondary（设置辅助微端口）API。

14.8 The request handler and the request complete handler should have knowledge of the OIDs that are redirected so that those requests will be completed on the miniport handles they were requested on.
14.8）请求句柄和请求完成句柄会确认OIDs已经被从定向，所以这些请求回在他们请求时被完成！


哎~~~好乱啊！！我希望大家能帮这把他整理一下~~我的e-mail是：[e-mail] 发一份给我吧！我也会把大家整理后发给我的passthru说明转发给所有参与整理的或要求转发的朋友！！谢谢~~~每人出份力帮助后进啊（好象有点假公济私~~呵呵）！我的QQ：12076827希望能和大家交流！！放心啦！虽然大家都是君子知交淡入水但我决不是那种在QQ上对人爱理不理的人啦！！加我啊！！！！期待交流！！孤军作战太苦闷！！哇~~~2点了！睡觉！明天起不来了！！