deviceiocontrol fails for bus driver
in [Device Drivers]
|
Prev: USB suspend issues
Next: Barcode scanner problem
From: DW on 22 Sep 2006 02:08 I will definitely go through the toaster sample as it also answers questions we haven't addressed yet, but have identified (such as installation). I realize the next question is loaded, but I wanted to get a feel for how feasible it would be to switch over to KMDF at this point in our development. We have a functional WDM bus/function driver for a multi-interface network card that is already controlled through a user-mode app via ioctls. The current work is to create a miniport filter driver (based on the samples of course) at its upper edge so that it can hook into the Window stack. The miniport is getting close to being minimally functional with the bus driver so that packets can be sent/received. Since we aren't experts at driver writing and the person who wrote the bus driver is no longer here (and there appears to be a lot of defunct code lying around in the driver), I am wondering how risky it would be (and whether it would save time) to jump ship to KMDF at this point. It's mainly the driver code that is not related to interacting with the hardware itself that concerns me since that part is not well understood by us. Do you think this transition can be done in a matter of weeks (the work is slated to be completed in another month) or does it sound like we are better off sticking with the older framework at this point? "Eliyas Yakub [MSFT]" wrote: > > > Is the sharing of a single device extension between two devices possible? > > I know > > that the call to IoCreateDevice automatically allocates a device > > extension, > > but would it be possible to pass in 0 for the second device's extension > > and > > then have the second device access the first device's extension? > > Assuming you did that. How would you get to the first device's extension > from the dispatch routine of the second device? > > I suggest you follow the toaster\filter sample. It shows how to create a > control device in a pnp driver and deal with all the synchronization and > driver unload issues. Read all the comments. > > > > > Another alternative I can think of is to register one device through NDIS > > (NdisMRegisterDevice) per functional/bus device and have the miniport > > forward > > the IOCTLs to the bus driver. This would eliminate the issues of having > > multiple device objects/extensions or sharing a device extension between > > multiple bus devices. > > > > The problem is that NdisMRegisterDevice doesn't allow you to have extension > unless you are writing NDIS6.0 driver. As a result, you have to use global > context to track all the states.\\ > > -Eliyas > >
From: Eliyas Yakub [MSFT] on 22 Sep 2006 13:38 It's a loaded question. Having ported innumerable number of drivers to KMDF, my confidence level is very high. Based on that and also keeping in mind that your driver is a bus driver, my suggestion would be to switch over to KMDF. In the short term, you will be faced with steep learning curve, hard work, but it will pay off heavily because it will take away all the complexity from you driver and enable you to just focus on hardware interaction. Testing and maintenance will be easier because you can rely on KMDF doing the right thing for you. When you do the conversion, you don't have to churn the code that interacts with the hardware. You can replace the pnp/power for FDO and PDO and escape to WDM for some of the I/O handling code. Just to share my experience, I converted inbox atapi.sys (bus driver for ide controller) to KMDF just for proof of concept. This driver is really a complex driver. I was really scared to churn the I/O code because I didn't want to spend months debugging it. The approach I took was that I replaced all the pnp/power, bus enumeration code to framework, used I/O queues to receive the I/O requests so that I can get the benefit of KMDF handling all the I/O sync issues (remlock, cancellation, etc) with pnp/power. When it came to processing requests, I escaped to WDM to get the IRP from WDFREQUEST and used the existing code that took the IRP and interacted with the hardware as is. It took about 4 weeks to port this driver. I took a similar approach to serial sample also. If you look at the WDM and KMDF versions of these samples, you will notice the I/O interaction hasn't changed at all (it's a legacy code with lot of timing issues). The flow of control when the I/O is received by the driver is as is. I just changed the shell around the I/O routines to confirm to KMDF. -- -Eliyas This posting is provided "AS IS" with no warranties, and confers no rights. http://www.microsoft.com/whdc/driver/tips/default.mspx
From: Maxim S. Shatskih on 23 Sep 2006 05:27 > Just to share my experience, I converted inbox atapi.sys (bus driver for ide > controller) to KMDF just for proof of concept. This driver is really a > complex driver. Is this effort included in Vista as its ATA stack? Second question: am I wrong that pre-Vista ATAPI.SYS is not only a storage port bus driver, but also can run _alone without a miniport_ over the classic-style IDE task file registers with "rep insw" PIO mode, and the miniports are for DMA only? Third question: before Vista, the drivers for custom IDE hardware (like HighPoint RAID etc), which is incompatible with classic IDE task file registers, were forced to be developed as... SCSI miniports. Will Vista change this with introducing something like a "general ATA port"? Is this "general ATA port" used for usual chipset-embedded IDE/ATA/SATA controllers? -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim(a)storagecraft.com http://www.storagecraft.com
From: Eliyas Yakub [MSFT] on 26 Sep 2006 21:24 > Is this effort included in Vista as its ATA stack? No. > > Second question: am I wrong that pre-Vista ATAPI.SYS is not only a storage > port > bus driver, but also can run _alone without a miniport_ over the > classic-style > IDE task file registers with "rep insw" PIO mode, and the miniports are > for DMA > only? There is no miniport for pre vista ATAPI. However, there is a miniport model at the lower controller driver level (PciIdex) called miniide on which ATAPI sits. From what I understand ATAPI doesn't always need the lower PciIdex driver to work. It can be standalone and do port I/O to the hardware directly. I guess that's how it works with pcimci flash storage devices. > > Third question: before Vista, the drivers for custom IDE hardware (like > HighPoint RAID etc), which is incompatible with classic IDE task file > registers, were forced to be developed as... SCSI miniports. Will Vista > change > this with introducing something like a "general ATA port"? Is this > "general ATA > port" used for usual chipset-embedded IDE/ATA/SATA controllers? > I don't think MS allows anybody to write their own miniport driver for ATA devices. I'm not a hardcore storage guy. So please take my response with a pinch of salt. -Eliyas
From: Maxim S. Shatskih on 27 Sep 2006 16:55
> From what I understand ATAPI doesn't always need the lower PciIdex driver to > work. It can be standalone and do port I/O to the hardware directly. I guess > that's how it works with pcimci flash storage devices. Am I correct that ATAPI queries some PnP interface down the devnode, and then, if the interface is absent, it uses the ports and PIO directly? And, if the interface is present (provided by PCIIDEX) - it uses the functions from this interface to do DMA? Is this correct? -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim(a)storagecraft.com http://www.storagecraft.com |