技术问题 有兴趣的来讨论讨论

最近看到WALTER ONEY的一篇Filtering Serial Port Modem Status的文章，文章中讲了关于解决两个应用程序同时操作对串口的共享冲突问题。
其中提到了一个EDO(external device object)的概念，大概的方法是在serial.sys的UpFilter.sys中建立两个DO，一个是常规的FIDO，一个就是EDO，众所周知，FIDO是没有自己的设备名的，而在这里替EDO设一个符号连接名，这样应用程序就可以访问EDO了，也就达到了共享串口的目的了。文章没有讲EDO的具体实现方法，呵呵，想听一下大家的看法。
先说一下自己的想法：
我认为EDO和FIDO在UpFilter中是共享一个设备扩展区（device_extension)的，因为他们处理IRP的方向都是下层的SERIAL
，我想在扩展区中加入虚拟的EDO的各种数据结构，并先创建常规的FIDO:deviceobject  :IoCreateDevice(DriverObject,sizeof    
                             (DEVICE_EXTENSION),
                             NULL,  // No Name for fido
                             deviceType,
                             FILE_DEVICE_SECURE_OPEN,
                             FALSE,
                             &deviceObject);
随后再创建EDO：ExdeviceObject  :
IoCreateDevice (DriverObject,
             0, //don't allocate memory for Edo's extension
             NULL,  // here name the external device object
             deviceType,
             FILE_DEVICE_SECURE_OPEN,
             FALSE,
             &ExdeviceObject);
然后再：ExdeviceObject->DeviceExtension = deviceObject->DeviceExtension;
这样EDO和FIDO就有了相同的扩展。
还有特殊的IRP的处理，比如REMOVE设备，要怎样区分是针对EDO的还是针对下层的FDO的？又比如REMOVE了下层的FDO了那么EDO就不存在了，要做特殊处理吗？

请大家讨论讨论

没有必要edo->deviceextention=fido->deviceextension
发给edo的irp，到edo就完了，不会也不能再发下去

比如你的xxxdispatchcreate:
NTSTATUS
xxxdispatchcreate(PDEVICE_OBJECT pDO, PIRP pIrp)
{
   if(pDO == edo)  // edo是在IoCreateDevice的时候记下的DeviceObj的地址
   {//edo的处理，一般就是完成返回
   }
   // else就是给fido的
}

实际上，filter driver一般都会创建一个所谓的“Control Device”来和自己的某个管理程序通讯

那应该怎么样将EDO处理的IRP传下去呢？

朋友门帮忙顶一下！！谢谢

What you *should* do is dream up some private naming convention for your
extra device object and use that private name in your call to
CreateFile. The IRP_MJ_CREATE will come to your DispatchCreate entry
directly rather than coming through the PnP device stack first. In fact,
all IRPs aimed at either the extra device object or the FiDO will come
to the same set of dispatch entries. You therefore need to provide a way
to distinguish between your two device objects. For this purpose, you
should define two device extension structures in your driver:

typedef struct _REAL_DEVICE_EXTENSION {
  ULONG flag;
  _EXTRA_DEVICE_EXTENSION* edx;
  PDEVICE_OBJECT fido;
  ...
  } REAL_DEVICE_EXTENSION, *PREAL_DEVICE_EXTENSION;

typedef struct _EXTRA_DEVICE_EXTENSION {
  ULONG flag;
  PREAL_DEVICE_EXTENSION rdx;
  PDEVICE_OBJECT xdo;
  ...
  } EXTRA_DEVICE_EXTENSION, *PEXTRA_DEVICE_EXTENSION;

typedef struct _COMMON_DEVICE_EXTENSION {
  ULONG flag;
  } COMMON_DEVICE_EXTENSION, *PCOMMON_DEVICE_EXTENSION;

So, in AddDevice, you create your FiDO with
sizeof(REAL_DEVICE_EXTENSION) as the its extension size, and you
initialize the FiDO's REAL_DEVICE_EXTENSION with a particular flag value
(e.g., 'LAER'). You also create your extra device object with
sizeof(EXTRA_DEVICE_EXTENSION) as its extension size, and you initialize
its EXTRA_DEVICE_EXTENSION with a different flag value (e.g., 'ARTX').
You point each extension to the other object's extension.

In your dispatch functions, you'll have the following boilerplate code:

NTSTATUS DispatchSomething(PDEVICE_OBJECT do, PIRP Irp)
  {
  if (((PCOMMON_DEVICE_EXTENSION) (do->DeviceExtension))->flag ==
'LAER')
    <pass IRP down stack>
  else
    <process IRP for extra device object>
  }

In other words, you use the flag value at the start of the device
extension to tell which object is the target of the IRP.

In your RemoveDevice function, you follow the pointer from the FiDO's
REAL_DEVICE_EXTENSION to the associated EXTRA_DEVICE_EXTENSION and
thence to the extra device object, for which you call IoDeleteDevice.
Then you can call IoDetachDevice and IoDeleteDevice for the FiDO.

--
Walter Oney
http://www.oneysoft.com

谢谢楼上的！
请问你写的是walter oney的PROGRAM THE WINDOWS DRIVER MODEL ED2？？？请问你有这本书的详细的电子版的吗？下载中心的我不能下载，麻烦你发上来好吗？或者发给我的邮相：kissfire1999@sohu.com  
万分感谢！！！！:)

这不是书上的.
看看这个,你会明白 !!
How To Send IOCTLs to a Filter Driver
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q262305