Re: NDIS WDM driver installation for multi-port NIC
- From: DW <DZ@xxxxxxxxxxxxx>
- Date: Thu, 28 Sep 2006 17:29:01 -0700
I looked again at the ndiswdm.inf and caught the line for Addservice. It's
the SPSVCINST_ASSOCSERVICE flags that I was missing. So this is the reason
why the netdrv.inf file installed both the ndiswdm driver and the pcidrv
driver at the same time--the ndiswdm driver was acting as a filter, but was
using the pcidrv driver as the function driver. Now that I have the infs
separate, each driver is acting as its own function driver.
I think I also understand now why the miniport got the device objects
differently. In the filter/function (ndiswdm/pcidrv) driver installation
combo, NdisMGetDeviceProperty would return back the function driver (pcidrv)
because the inf files linked the two driver togethers. However, when
installed as a separate function driver (ndiswdm only), the driver has to now
figure out who to talk to, depending on how it was installed.
Am I correct in undersstanding that in my case, because I've created a PDO
for the port from the c5ebus driver, the miniport can use the PDO to retrieve
the bus driver's FDO and send IRPs to that device object?
Does this also mean that when the miniport is not installed as a filter
driver but as a function driver, that any interfaces that the c5ebus
registers is now accessible once again by a user application since the c5ebus
driver is once again at the top of the device stack?
"Eliyas Yakub [MSFT]" wrote:
My suggestion would be to keep the bus driver separate from the ndis-wdm.
driver. In other words, install the ndis-wdm driver as a function driver
for the ports that you enumerate and not use that as an upper filter of bus
driver for one of the ports.
This is what I would do:
1) Define a new setup class for your bus driver (C5eBus.sys) and install
that under that class. I wouldn't use System class. If you ever go to MS for
logo, they wouldn't like if you use System class for your PCI device. You
can use the first INF that you posted for this. You have to add
ClassInstall32 section to create your own class. Take a look at the
toaster.inf sample. Create a new guid to represent your class. You shouldn't
have any NDIS specific directive in this file such as characteristics,
BuyType. This bus driver would then do a static enumeration or enumerate
ports based on application command.
2) Install the ndisedge as a function driver for the child devices you
enumerate. Your second INF (Net Class) looks good to me. I suggest you don't
use ndisedge as the name of the miniport driver. This is the name of the
sample driver. If another vendor uses the same name for his driver then you
will run into issues. Come up with your own unique name.
Now the question is that how independent the child devices are. What if I
disable one child device, will the others devices get affected by that.
I don't think you have issues with sharing hardware resources because by
using NDIS-WDM driver, the miniport is going to send the data down and your
bus driver will interface with the hardware at the PDO level. Correct?
--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/driver/tips/default.mspx
- Follow-Ups:
- Re: NDIS WDM driver installation for multi-port NIC
- From: Eliyas Yakub [MSFT]
- Re: NDIS WDM driver installation for multi-port NIC
- References:
- Re: NDIS WDM driver installation for multi-port NIC
- From: Eliyas Yakub [MSFT]
- Re: NDIS WDM driver installation for multi-port NIC
- Prev by Date: Re: kbfiltr sample and Windows Vista...
- Next by Date: Re: NDIS WDM driver installation for multi-port NIC
- Previous by thread: Re: NDIS WDM driver installation for multi-port NIC
- Next by thread: Re: NDIS WDM driver installation for multi-port NIC
- Index(es):
Relevant Pages
|