驱动间相互调用的问题

现有两个PCI设备，驱动已经写好。现在需要在一个设备的ISR中判断另一个设备的状态，并且调用另一个设备的DPC，是否可行？

如果可行，具体应该怎么做？比如，如何得到另一个设备的FDO……

假如不可行，怎样实现我所需要的功能，即第一个设备的中断信号来时，除了做自己的处理，还要对另一个不能响应这个中断信号的设备做一些处理？

按照书上所说，ISR应该尽快的完成的啊！
可以通过IOGETDEVICEOBJECTPOINT来得到设备对象，不过需要知道这个设备的名称

按照书上所说，ISR应该尽快的完成的啊！
可以通过IOGETDEVICEOBJECTPOINT来得到设备对象，不过需要知道这个设备的名称

假如用的是设备接口而不是符号连接名，如何调用此函数？
并且好象此函数是分层驱动中上层调用，而我需要同级之间的互相调用，可以吗？是否还要控制好同级几个驱动的装入顺序？

按照书上所说，ISR应该尽快的完成的啊！
可以通过IOGETDEVICEOBJECTPOINT来得到设备对象，不过需要知道这个设备的名称

我用的是设备接口，没有用符号连接名，是否就不能调用这个函数。而且我看到这个函数一般是在分层驱动程序中使用，用来获取低层的设备对象，而我的两个驱动应该是同一层次，是否可用？是否需要控制OS的加载顺序？

引用：
--------------------------------------------------------------------------------
按照书上所说，ISR应该尽快的完成的啊！
可以通过IOGETDEVICEOBJECTPOINT来得到设备对象，不过需要知道这个设备的名称
--------------------------------------------------------------------------------



我用的是设备接口，没有用符号连接名，是否就不能调用这个函数。而且我看到这个函数一般是在分层驱动程序中使用，用来获取低层的设备对象，而我的两个驱动应该是同一层次，是否可用？是否需要控制OS的加载顺序？

将你的驱动设置成为EXPORT_DRIVER，然后导出几个函数就可以像调用动态连接库一样调用了。

用IOGETDEVICEOBJECTPOINT就要有设备名，不是符号连接名，是在IOCREATEDEVICE（）中定义的设备名。
斑竹建议使用EXPORT DRIVER，不知是否自己试过？有没有例子可供大家学习？
我用EXPORT DRIVER时，如果调用者先于服务者加载，就会出现加载过程的混乱。不知斑竹是否碰到过这种情况？

用IOGETDEVICEOBJECTPOINT就要有设备名，不是符号连接名，是在IOCREATEDEVICE（）中定义的设备名。
斑竹建议使用EXPORT DRIVER，不知是否自己试过？有没有例子可供大家学习？
我用EXPORT DRIVER时，如果调用者先于服务者加载，就会出现加载过程的混乱。不知斑竹是否碰到过这种情况？

我试过的阿，工作的很好的，我的驱动之一是手工启动，另外一个是自动启动，所以启动顺序必然没有问题。

可你不能让用户每次开机都手工添加硬件。如果都自动启动，就有顺序问题了。

那可以用手动方式，然后用自动运行的应用程序来启动

simba:
你做过自动加载WDM的程序？
动态加载WDM的问题好象还没人解决过。

动态加载WDM的问题好象还没人解决过。

faint,不知怎么的出的结论，呵呵 :D :D :D

引用：
--------------------------------------------------------------------------------

动态加载WDM的问题好象还没人解决过。
--------------------------------------------------------------------------------


faint,不知怎么的出的结论，呵呵  

--------------------------------------------------
到各个新闻网站搜索帖子。问这个问题的人老了，结论基本是NT DRIVER可以，WDM NO。
或许老兄有什么办法，我很想知道。

到各个新闻网站搜索帖子。问这个问题的人老了，结论基本是NT DRIVER可以，WDM NO。
或许老兄有什么办法，我很想知道。
 

你是说用程序安装问题，使用Setup诸api，以前有很多人提过，NTDDK亦有例子，没KMD那么方便，大家都说腻了，自己找找吧。
但这里有此法解决这问题，每次都安装一遍实在不是好办法。

拜托，什么叫动态加载，先搞搞明白。

拜托，什么叫动态加载，先搞搞明白。

自然明白。想想KMD是怎样所谓“动态加载”的吧，是你的程序先用api安装驱动好了之后再加载并调用入口，它有一方便性在于不必卸载使得下次少一步。而WDM亦是先安装再加载，只是它要与pnp管理器协同，不卸掉pnp会自作多情加载。他们加载的原理是一样的（相同的未导出核心函数加载），只是多了一个不大听你话的pnp。

另外，我是对你这句话说的：“可你不能让用户每次开机都手工添加硬件。如果都自动启动，就有顺序问题了”
以为你只知用手工加的办法，......。不让用户做，自己程序作还不是一样，不过不好。

还有fracker说的第二个估计是KMD

[编辑 -  1/3/03 by  kernel_kernel]

斑竹啊，你躲到哪里去了？
你有没有试过颠倒一下您的两个程序的加载次序？有没有发现过我说的现象？
我很想知道是不是我的驱动本身有问题，还是提供API的程序必须最早加载？

 StartType, LoadOrderGroup, and Dependencies entries.


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/install/hh/install/create-inf_7ap3.asp

zdhe
那些没用，你肯定没试过。

看来看去，似乎是同样级别的两个pci设备，使用了两个设备驱动程序。而且启动层次似乎相同。

tim说的这种情况确实可能出现，两个同样层次的driver确实不能简单指定依存关系。对于bus-> enum device的模式而言，没有遇到过这种问题。 bus设备永远比插在bus上的东西先被enum出来。所以可以先装载bus, 然后又足够的机会给下面的一村设备一个一个得装载设备驱动。如果两个设备没有任何物理联系，而逻辑联系也局限在似乎是实装需要的得情况下，系统自举时不能确定哪一个先被enum出来，所以问题就都出来了。（看过的哪本书上说过系统如何ｅｎｕｍ设备，具体记不的了，有一点依稀有些印象，就是它按照逻辑ｓｌｏｔ从ｍｉｎ　到ｍａｘ　逐个干？）。　我不知道如何让系统先enum那个，后enum那个。奇怪，既然一个的运行要检测另一个的状态，干吗不做在一个卡上？

似乎是体系设计问题。

关于export driver，可以参考walteroney的generic.sys.在这个站点上可以找到书籍和附属cd的source。（如果ｄｏｗｎ不下来，我
可以发给你）

通过下层的export driver，可以把所有的处理集中在一个包括数据区彼此完全透明的地方，看来只有暂时让程序逻辑去处理被依存设备还没有启动的情况了。

如何让exporｔ　ｄｒｉｖｅｒ　比这两个宝贝先启动，又回到了上面的启动顺序的讨论。


如果只是设备启动程序的启动次序，即使如我理解两个设备驱动程序处于完全相同的层次也可以指定启动的先后顺序。参考下面的文章就是



HOWTO: Control Device Driver Load Order
The information in this article applies to:
Microsoft Win32 Device Driver Kit (DDK) for Windows NT 3.1
Microsoft Win32 Device Driver Kit (DDK) for Windows NT 3.5
Microsoft Win32 Device Driver Kit (DDK) for Windows NT 3.51
Microsoft Win32 Device Driver Kit (DDK) for Windows NT 4.0
Microsoft Win32 Device Driver Kit (DDK) Windows 2000

This article was previously published under Q115486
SUMMARY
Windows NT is designed around the concept that the first driver to claim a device obtains ownership of that device. This ownership can be shared or it can be exclusive; this is up to the claiming device driver. If the device is exclusively claimed by a device driver, any further attempts to claim the device by subsequently loaded device drivers fail. Because of this, it is imperative that the order in which device drivers load can be modified by device driver authors. This article describes the two methods that you can use to control the order in which device drivers load.
MORE INFORMATION
There are two methods that you can use to control the order in which device drivers load. Both methods take advantage of entries in the registry that can be found at \\HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control. The first method is to modify the ServiceGroupOrder. The second method is to assign Tag values that determine the order of driver loading according to the GroupOrderList. The tag values start type and Group names are in the HKLM\\SYSTEM\\CurrentControlSet\\Services\\<drivername> key which must be added before the values can be listed in the Group Order List.

These two methods only work for device drivers that have a start value of 0 (SERVICE_BOOT_START) or 1 (SERVICE_SYSTEM_START). In all cases, device drivers with a start value of 0 load before any device drivers with a start value of 1 attempt to load.
Method 1: ServiceGroupOrder
The ServiceGroupOrder contains a list of group names in the order that they will be loaded. Here are the unmodified contents of ServiceGroupOrder:



SCSI miniport
port
Primary disk
SCSI class
SCSI CDROM class
filter
boot file system
Base
Pointer Port
Keyboard Port
Pointer Class
Keyboard Class
Video Init
Video
Video Save
file system
Event log
Streams Drivers
NDIS
TDI
NetBIOSGroup
SpoolerGroup

According to the ServiceGroupOrder, device drivers in the group \"SCSI class\" load after all device drivers in the group \"Primary disk\" and before device drivers in the group \"SCSI CDROM class\" load. The higher a device driver\'s group is in the list, the sooner it loads. The ServiceGroupOrder list is scanned twice. First, all device drivers with a start value of 0 load; then, all device drivers with a start value of 1 load. Thus, a device driver with a start value of 0 loads before any device driver with a start value of 1, no matter what its position on the ServiceGroupOrder list.

It is possible for the device driver author to edit the ServiceGroupOrder. By doing this, a new group can be created at any place in the list. A good example might be a SCSI class device driver called \"SAMPLDRV\" needing to load before \"SCSIDISK\" because SCSIDISK is claiming a device that SAMPLDRV needs to claim. Here are SCSIDISK\'s registry entries:

       \\registry\\machine\\system\\currentcontrolset\\services\\scsidisk
          Type = REG_DWORD 0x00000001
          Start = REG_DWORD 0x00000000
          Group = SCSI class
          ErrorControl = REG_DWORD 0x00000000
          DependOnGroup = REG_MULTI_SZ \"SCSI miniport\"


A new group can be added to the ServiceGroupOrder called \"Load Me First\" and SAMPLDRV can have its group set to Load Me First. Here is the modified ServiceGroupOrder:



SCSI miniport
port
Primary disk
Load Me First
SCSI class
SCSI CDROM class
filter
boot file system
.
.
.

Here are SAMPLDRV\'s registry entries:

       \\registry\\machine\\system\\currentcontrolset\\services\\sampldrv
          Type = REG_DWORD 0x00000001
          Start = REG_DWORD 0x00000000
          Group = Load Me First
          ErrorControl = REG_DWORD 0x00000000
          DependOnGroup = REG_MULTI_SZ \"SCSI miniport\"


With this configuration, SAMPLDRV loads before SCSIDISK.
Method #2: GroupOrderList and Tag Values
An optional key called Tag can be included in a device driver\'s registry. The value of the Tag helps determine the loading order of the device drivers within a group. The loading order is not necessarily in numerical order; rather, it is in the order defined by the GroupOrderList. The first entry per group in the GroupOrderList is the number of Tag values. This is followed by the numerical sequence in which the Tag values are to be loaded. Device drivers in a group are first loaded according to their Tag value as defined by the GroupOrderList. If the device driver does not have a Tag value or if the Tag value is not in the GroupOrderList, then these device drivers load after the device drivers with valid Tag values load. For these device drivers, the order of loading is not guaranteed, other than that all device drivers in a group load before the next group loads.

Here is a partial output of the GroupOrderList:

      \\registry\\machine\\system\\currentcontrolset\\control\\grouporderlist
          Base = REG_BINARY 0d 00 00 00 01 00...
          Extended base = REG_BINARY 04 00 00 00 01 00...
          Filter = REG_BINARY 05 00 00 00 01 00...
          Keyboard Class = REG_BINARY 01 00 00 00 01 00...
          Keyboard Port = REG_BINARY 01 00 00 00 01 00...
          Ndis = REG_BINARY 09 00 00 00 01 00...
          Pointer Class = REG_BINARY 01 00 00 00 01 00...
          Pointer Port = REG_BINARY 03 00 00 00 01 00...
          .
          .
          .


NOTE: There is no value for SCSI class. Not every group is represented in the GroupOrderList. When a group is not in the GroupOrderList, the order in which device drivers load within the group cannot be guaranteed.

As with the ServiceGroupOrder, the GroupOrderList can be modified. Using the same example as above, Tag entries for SCSI class can be added:

      \\registry\\machine\\system\\currentcontrolset\\control\\grouporderlist
          SCSI class = REG_BINARY 02 00 00 00 02 00 00 00 01 00 00 00
          Base = REG_BINARY 0d 00 00 00 01 00...
          Extended base = REG_BINARY 04 00 00 00 01 00...
          .
          .
          .


In this example, the group SCSI class recognizes two Tag values, 00000001 and 00000002. The order in which the Tag values load is 00000002 first, followed by 00000001. If SAMPLDRV is in the SCSI class group, which is the same as SCSIDISK, either Tag value guarantees that SAMPLDRV loads before SCSIDISK because SCSIDISK has no Tag value and non-Tagged drivers load last in a group.

If for some reason SCSIDISK is assigned a Tag value of 0x00000001, SAMPLDRV loads before SCSIDISK when SAMPLDRV is assigned a Tag value of 00000002:

       \\registry\\machine\\system\\currentcontrolset\\services\\sampldrv
          Type = REG_DWORD 0x00000001
          Start = REG_DWORD 0x00000000
          Group = SCSI class
          ErrorControl = REG_DWORD 0x00000000
          DependOnGroup = REG_MULTI_SZ \"SCSI miniport\"
          Tag = REG_DWORD 0x00000002