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