I am currently porting a driver suite I have written for NT 4.0 to Windows
2000. It will be WDM and PnP compatible, but there will be no need to take
it down to 9x or ME. The suite is a layered model with a functional lower
layer that provides a private DLL interface to upper layer drivers for our
fibrechannel hardware. I chose to interface the drivers using a private DLL
interface because one driver is a SCSI miniport and does not have the
standard means of inter-driver communications available (IoCallDriver).
Simply stated, the function driver loads, hooks the PCI resources, and waits
for the upper layer drivers to register themselves, via a DLL entry point,
when they load.
I think that this easily lends itself to a bus/function/filter model in
Win2K, but where is the best place to put the FDO? The function driver’s
response to IRP_MN_START_DEVICE will be to handle the PCI information and
hook the ISR. Is it best to make it part of the bus driver, reducing the
number of drivers that have to be written or ported, or is it best to keep
its functionality separate?
Is this one of those “Gee I wish I had done it the other way …” when it’s
finally shipped?
Any thoughts?
Gary
Hi, Gary,
I’m afraid I don’t have a good mental picture of this. My experience though
with such things is that you really have to prototype the design to really
say if it’s the right thing or not.
It SOUNDS like breaking it up into bus driver/function driver is the way to
go, but… you know how that can be.
— Jamie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary Little
Sent: 2000-October-03 Tuesday 09:36
To: NT Developers Interest List
Subject: Porting to Windows 2000 …
I am currently porting a driver suite I have written for NT 4.0 to Windows
- It will be WDM and PnP compatible, but there will be no need to take
it down to 9x or ME. The suite is a layered model with a functional lower
layer that provides a private DLL interface to upper layer drivers for our
fibrechannel hardware. I chose to interface the drivers using a private DLL
interface because one driver is a SCSI miniport and does not have the
standard means of inter-driver communications available (IoCallDriver).
Simply stated, the function driver loads, hooks the PCI resources, and waits
for the upper layer drivers to register themselves, via a DLL entry point,
when they load.
I think that this easily lends itself to a bus/function/filter model in
Win2K, but where is the best place to put the FDO? The function driver’s
response to IRP_MN_START_DEVICE will be to handle the PCI information and
hook the ISR. Is it best to make it part of the bus driver, reducing the
number of drivers that have to be written or ported, or is it best to keep
its functionality separate?
Is this one of those “Gee I wish I had done it the other way …” when it’s
finally shipped?
Any thoughts?
Gary