NDIS如何管理各层驱动的？请知道的指点一下，谢谢

我在看DDK时很困惑，不知道NDIS如何管理各层驱动的，比如说，DDK说中间层驱动的一个目的是插在上层驱动和网卡微端口驱动之间，作些处理的；但对于上层驱动来说，它不知道有一个中间驱动，对下层驱动来说，它不知道有中间层驱动。道理是说得通的，但不知DNIS如何做到的，因为对于中层驱动和下层驱动来说，它们都认为自己帮定在微端口驱动之上，我看了2000 DDK自带的代码,好像哪些函数（NdisIMRegisterLayeredMiniport，NdisRegisterProtocol等）都没有实现一个标志说该驱动在插在那个位置，到底是如何实现的哪？

[quote][quote]请仔细看Passthru的例程。不管是hook方式还是中间层，
其实质都是一样的：用自己的程序地址替代系统NDIS函数入口，
即使系统先调用我们的程序，再走原来的流程
 

你这样说Passthru对吗？我有点怀疑。 [/quote]
肯定不对，passthru不是替换的程序地址，他本身是一个小端口和一个协议层的结合体，一定程度上和你自己写一个协议在写一个小端口然后让他们配合工作是一样的。 [/quote]

既然是这样，那么PASSTHRU和SPI模型有没有相同性？
我的理解是这这样的，中间层驱动在NDIS里的存在方式是不是和SPI差不多？只要是符合中间层驱动的规范（上面一个微端口，下面一个协议驱动），都可以插入到NDIS里去，就好像是SPI，每个SPI DLL都要引出一个WSPStartup函数，然后可以多个SPI DLL可以叠加在一起，那么中间层驱动应该也是这样，多个中间层驱动叠加在一起组成数据的传输通道。

不知道我的理解有没有错误？
我感觉大体是这样的，请大虾指教

WinXP中的pppoe拨号驱动应属于NDIS哪一种驱动哪？

microsoft.public.development.device.drivers

你在微软的那个新闻组里面问的？

同时我在Net 安装节看到有UpperRange和LowerRange两个键，是不是这些也有关系哪？

我在微软的新闻组上也提出了这个问题，其中有人回复如下：

The layering of filter IM drivers is controlled by the IM driver\'s INF
entry FilterClass.  Per the DDK, this should be one of the following:
\"scheduler\" (highest in the stack), \"loadbalance\" and \"failover\" (lowest of
the IM drivers in a stack).  Also, per the documentation, only one of each
class should be present in the system at any time.  If there is more than
one, the exact layering is indeterminate (and I think you may hit an assert
in a checked build, but I haven\'t tested).  In actuality, you can create
your own class by using your own string.  If you do that, all such IM
drivers are layered above \"scheduler\".  If there are multiple \"custom\"
classes, their order is indeterminate, too - it depends on the order that
the binding engine discovers it.  The ordering of \"scheduler\",
\"loadbalance\" and \"failover\" are dictated in the registry at
HKLM\\System\\CurrentControlSet\\Control\\Network\\FilterClasses, but I wouldn\'t
recommend changing that value, as it may open long-term supportability and
upgrade issues.  You might be able to fine-tune the layering with a notify
object or via the INetCfg APIs.

The layering of MUX IM drivers is completely different and don\'t follow the
rules above.

I hope this helps.

Bryan S. Burgin
bburgin@microsoft.com

This posting is provided \"AS IS\" with no warranties

大家认为按他说的可不可以？

好象是有一个标志的，是用函数NdisMSetAttributesEx来设置的。

[quote]请仔细看Passthru的例程。不管是hook方式还是中间层，
其实质都是一样的：用自己的程序地址替代系统NDIS函数入口，
即使系统先调用我们的程序，再走原来的流程
 

你这样说Passthru对吗？我有点怀疑。 [/quote]
肯定不对，passthru不是替换的程序地址，他本身是一个小端口和一个协议层的结合体，一定程度上和你自己写一个协议在写一个小端口然后让他们配合工作是一样的。

例子我看了，但上述疑点还没有消除，如果是系统帮我们做了工作，
那么如果有两个中间层驱动都想对以太网原始包做些处理，碰巧又两个都安装了，那不是有一个要出错？如果不是系统帮助做了，那么我们应怎样做哪？请多多指教，谢了。

请仔细看Passthru的例程。不管是hook方式还是中间层，
其实质都是一样的：用自己的程序地址替代系统NDIS函数入口，
即使系统先调用我们的程序，再走原来的流程
 

你这样说Passthru对吗？我有点怀疑。

请仔细看Passthru的例程。不管是hook方式还是中间层，
其实质都是一样的：用自己的程序地址替代系统NDIS函数入口，
即使系统先调用我们的程序，再走原来的流程

我不是那个意思，我迷惑的是为什么代码中没有标记指示驱动的位置
，举例来说，假定我们有一个中间驱动程序，它要来包装一个底层网卡驱动的数据包，之后转发给中/高层驱动(假定是IP驱动），在我们的驱动没有安装之前高层驱动运行正常，在我们的驱动安装之后，一样正常，但细节却不一样了，（如图，收包：
之前：网卡驱动==>             IP==>TCP==>应用程序
之后：网卡驱动==>我们的驱动==>IP==>TCP==>应用程序）
因为对于IP驱动来说，它始终认为自己帮定在网卡上，我们的驱动也并不知道上层是IP协议，它只道上层是协议层而已，但DNIS显然知道应先发包给我们的驱动，如果不是这样，哪我们的驱动就没有用了。
实例是
1：2000下的 NDISWAN驱动,它将LAN格式数据换成WAN格式。
2：ATM LANE（LAN仿真）驱动，它将无连接的数据格式成ATM格式
3：XP下的PPPoE拨号驱动，它正如上述，在IP之前，网卡之后

关键在于，代码实例和DDK中好像都没明确说明实现的细节（为什么我们的驱动不知道上下细节，NDIS却知道？我们如何向NDIS说明我们在IP之前的？）我们如何做设计和编码工作才能达到上述目的？

在NdisRegisterProtocol等函数内部包装了IoCreateDevice等函数，由它们来完成了，所以，通常你不需要直接调用IoCreateDevice来创建设备，因此就你看来不知道它们的层次关系，但OS却很明确的