deviceiocontrol fails for bus driver
in [Device Drivers]
|
Prev: USB suspend issues
Next: Barcode scanner problem
From: DW on 20 Sep 2006 19:18 The question about choosing the interface that NDIS uses is moot with your explanation; once the bus driver is linked into the NDIS framework, NDIS controls much of the communication with the driver. Thank you for the insight! I'll be sure to give an update once I get a chance to try this out. "Eliyas Yakub [MSFT]" wrote: > I mean another named device object using IoCreateDevice. > > Device interface is the recommended approach but when the request has to go > thru port drivers or class drivers, it's upto the whims of those models to > decide whether something should be allowed or not. > > > If the bus driver were to register an interface that > > only NDIS uses and another control interface that the API uses, then how > > would the miniport driver/NDIS be told to use a specific interface? > > You lost me here. NDIS doesn't use any interface so what do you mean by > that. > > > -- > -Eliyas > This posting is provided "AS IS" with no warranties, and confers no rights. > http://www.microsoft.com/whdc/driver/tips/default.mspx > >
From: Doron Holan [MS] on 20 Sep 2006 23:54 an alternative to the control device is to enumerate a raw PDO. If you have more then one device, you will have a one control for N devices so you will have to build an addressing scheme into the i/o you use to the control device. if you use a raw PDO, you have a 1:1 relationship with a PDO to a device. in addition, you can use a device interface for the raw PDO while you must use an nt4 fixed name for the control device. the KMDF kbdftilr example demonstrates this raw PDO technique. d -- Please do not send e-mail directly to this alias. this alias is for newsgroup purposes only. This posting is provided "AS IS" with no warranties, and confers no rights. "Eliyas Yakub [MSFT]" <eliyasy(a)online.microsoft.com> wrote in message news:e$i84VO3GHA.1548(a)TK2MSFTNGP02.phx.gbl... > Whoa! I didn't expect somebody would do that. You have updated the lower > driver (pcidrv equivalent) to be a bus driver. You are welcome to do that. > > Are you opening the ndis interface to talk to your bus driver? Or is your > bus driver is registering another interfaces on the FDO? In either case, > when the app opens the handle to the device-interface, it's going to go > thru NDIS. NDIS doesn't allow random ioctls to go thru the stack. That's > why you are seeing failures. So you have to workaround that by creating a > control-device in your bus driver and have the app talk to that. > > BTW, are you using KMDF to write the bus driver. If you answer yes, you > will get a personal thank you note from me. > -- > -Eliyas > This posting is provided "AS IS" with no warranties, and confers no > rights. > http://www.microsoft.com/whdc/driver/tips/default.mspx
From: DW on 21 Sep 2006 19:28 I don't suppose a similar technique is available in the older framework? I'm not currently using KMDF... "Doron Holan [MS]" wrote: > an alternative to the control device is to enumerate a raw PDO. If you have > more then one device, you will have a one control for N devices so you will > have to build an addressing scheme into the i/o you use to the control > device. if you use a raw PDO, you have a 1:1 relationship with a PDO to a > device. in addition, you can use a device interface for the raw PDO while > you must use an nt4 fixed name for the control device. > > the KMDF kbdftilr example demonstrates this raw PDO technique. > > d > > -- > Please do not send e-mail directly to this alias. this alias is for > newsgroup purposes only. > This posting is provided "AS IS" with no warranties, and confers no rights. > > > "Eliyas Yakub [MSFT]" <eliyasy(a)online.microsoft.com> wrote in message > news:e$i84VO3GHA.1548(a)TK2MSFTNGP02.phx.gbl... > > Whoa! I didn't expect somebody would do that. You have updated the lower > > driver (pcidrv equivalent) to be a bus driver. You are welcome to do that. > > > > Are you opening the ndis interface to talk to your bus driver? Or is your > > bus driver is registering another interfaces on the FDO? In either case, > > when the app opens the handle to the device-interface, it's going to go > > thru NDIS. NDIS doesn't allow random ioctls to go thru the stack. That's > > why you are seeing failures. So you have to workaround that by creating a > > control-device in your bus driver and have the app talk to that. > > > > BTW, are you using KMDF to write the bus driver. If you answer yes, you > > will get a personal thank you note from me. > > -- > > -Eliyas > > This posting is provided "AS IS" with no warranties, and confers no > > rights. > > http://www.microsoft.com/whdc/driver/tips/default.mspx > > >
From: DW on 21 Sep 2006 20:00 After thinking about this for a bit, if I create another device, either I would have to partition the functionality between the devices such that they don't overlap so that the data stored in the extensions doesn't have to be shared (which may not be possible since they both have to communicate with the hardware) or I would have to share the device extension between the two devices and just make sure that all of the data is locked/synchronized. 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? 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. "Eliyas Yakub [MSFT]" wrote: > I mean another named device object using IoCreateDevice. > > Device interface is the recommended approach but when the request has to go > thru port drivers or class drivers, it's upto the whims of those models to > decide whether something should be allowed or not. > > > If the bus driver were to register an interface that > > only NDIS uses and another control interface that the API uses, then how > > would the miniport driver/NDIS be told to use a specific interface? > > You lost me here. NDIS doesn't use any interface so what do you mean by > that. > > > -- > -Eliyas > This posting is provided "AS IS" with no warranties, and confers no rights. > http://www.microsoft.com/whdc/driver/tips/default.mspx > >
From: Eliyas Yakub [MSFT] on 21 Sep 2006 23:54
> 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 |